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Abstract of EP0592213 

An apparatus which provides a high data transfer 
rate to and from an asynchronous bus. The 
apparatus includes a synchronous logic network 
to provide a transaction connection between the 
asynchronous bus and the data transfer device 
during an initial phase of the transaction when 
many determinations are required and an 
asynchronous logic network to provide data 
transfer between the asynchronous bus and the 
data transfer device during a subsequent phase 
of the transaction when very few determinations 
are required. 
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(54) Synchronous/asynchronous partitioning of an asynchronous bus interface. 



(57) An apparatus which provides a high data 
transfer rate to and from an asynchronous bus. 
The apparatus includes a synchronous logic 
network to provide a transaction connection 
between the asynchronous bus and the data 
transfer device during an initial phase of the 
transaction when many determinations are re- 
quired and an asynchronous logic network to 
provide data transfer between the asynchron- 
ous bus and the data transfer device during a 
subsequent phase of the transaction when very 
few determinations are required. 
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BACKGROUND OF INVENTION: 

This invention relates generally to computer sys- 
tems, and more particularly to the transfer of data be- 
tween a data transfer device and an asynchronous 
portion of a computer system. 

As it is known in the art, computer systems gen- 
erally include at least one central processing unit 
(CPU), a main memory for storing data, at least one 
input/output (I/O) device, and a system bus coupling 
the aforementioned devices to the CPU. The I/O de- 
vice generally has a port which is coupled to an I/O 
bus which provides for access to one or more periph- 
erals. 

Generally, I/O devices are used to transfer data 
between the system bus and the I/O bus such that 
peripherals resident on the I/O bus are coupled to the 
remainder of the computer system. Many different 
types of peripherals, such as mass storage devices, 
i.e., disk drives, tape drives, etc., printers, other com- 
puter systems, and other I/O busses, etc., may be res- 
ident on the I/O bus. These peripherals generally 
have many different characteristics, including the 
speed at which they operate. Often, to take advan- 
tage of the operating speed of the fastest devices 
while still allowing slower devices to operate on the 
I/O bus, the I/O bus is provided as an asynchronous 
bus. An asynchronous bus is one in which there is no 
common clock or timing signal from which other sig- 
nals, such as address, data, and control signals, are 
related. Asynchronous bus is one is which all devices 
on the bus assert and deassert bus signals relative 
to transitions, i.e., assertions and/or deassertions, of 
a common clock or timing signal. 

Asynchronous busses generally operate via 
handshake signals sent between devices on the bus. 
Each handshake signal is usually associated with one 
or more bus signals, and if one device causes a tran- 
sition of a handshake signal, for example, an address 
strobe handshake signal, this usually indicates that 
its associated signals, i.e., the address signals, are 
valid. All appropriate devices on the bus will assert a 
corresponding handshake signal to indicate that they 
received the signals, i.e., address signals. In this 
manner, a fast device can communicate with a slow 
device by waiting for the slow device's related hand- 
shake signals which allows each device to operate as 
fast as possible. 

Generally, it is necessary in a computer system 
such as the one described above, to transfer data to 
and from the asynchronous I/O bus. Prior techniques 
use a bus interface circuit to control transfers with the 
asynchronous bus. One technique synchronizes the 
asynchronous bus handshake signals prior to using 
them. Aproblem with this approach is that it limits the 
speed of the data transfer rate. An alternative ap- 
proach is to use an asynchronous interface to transfer 
data with the asynchronous bus. An advantage of this 



approach is that data transfer on the asynchronous 
bus is very fast Adisadvantage is that the asynchron- 
ous interface is generally very complicated and ex- 
pensive. 

5 As is also known, a bus transaction, whether syn- 
chronous or asynchronous, generally involves a com- 
mand/address phase or cycle, which may be an initial 
transfer of information related to the transaction being 
initiated, followed by a data phase or cycle, which may 

10 be many transfers of data. A device performs a trans- 
action on the bus by first gaining access to the bus 
through some form of bus arbitration. After gaining 
access, the device begins the transaction by sending 
a command and an address on the bus (com- 

15 mand/address phase). All devices on the bus exam- 
ine the address and command. The devices often 
check for parity and other errors. The devices also 
decode the address to determine if they are a target, 
hereinafter referred to as a bus slave device, of the 

20 transaction. The bus slave device or devices must fur- 
ther decode the command and address information to 
determine the appropriate logical path to follow. 
Busses, particularly I/O busses where many different 
types of peripherals having different characteristics 

25 may reside, are very complicated. There may be sev- 
eral ways for a device to proceed after decoding the 
address and command information. 

Whether the bus is a synchronous or asynchron- 
ous bus, transaction control of the bus is often provid- 

30 ed by state machines, i.e., sequential circuits. One 
type of state machine is a synchronous state machine 
which uses storage elements called flip-flops that are 
allowed to change their binary value only at discrete 
instants of time. Synchronous state machines gener- 

35 ally include combinatorial logic circuits which imple- 
ment so called "state equations". The state equations 
define the operation or flow of the state machine. In 
response to the outputs from the combinatorial logic 
circuits, the flip-flops generate output bits termed 

40 state bits which define the states of the state ma- 
chine. The combinatorial logic receives inputs from 
external logic and the flip-flops, and provides outputs 
to external logic and to the flip-flops. The transition of 
a clock signal allows the flip-flops to operate on their 

45 input signals to produce the next output states of the 
flip-flops. The cycle time, i.e., assertion edge to as- 
sertion edge, of the clock signal may be chosen to be 
the smallest value which will allow the flip-flops to op- 
erate on their input signals and allow the combinator- 

50 ial logic to operate on the changed inputs from the 
flip-flops. Therefore, the clock signal may not transi- 
tion until the flip-flop inputs are valid, i.e. settled from 
transition, "glitch-free", or "noise-free", and have been 
valid for at least a time equal to the input set up time 

55 of the flip-flops. While this requirement prevents the 
synchronous state machine from changing state pre- 
maturely or incorrectly due to glitches, it also limits 
the speed of the state machine to the clock cycle 
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which is limited to the propagation delay through the 
slowest path. 

An I/O device which utilizes a synchronous state 
machine to transfer data with an asynchronous bus 
must also synchronize all the received asynchronous 5 
bus handshake signals prior to using them. To syn- 
chronize asynchronous signals, a two stage flip-flop 
apparatus may be used, i.e., a dual stage synchron- 
izer. With a dual stage synchronizer, the asynchron- 
ous signal is fed to a first flip-flop input and the syn- 10 
chronizing clock is used to allow the signal value to 
pass through the flip-flop appearing at an output of 
the first flip-flop if the signal reaches the flip-flop pri- 
or to the clock transition. The output from the first flip- 
flop is then fed into an input of a second flip-flop 15 
which is controlled in a similar fashion by the clock 
signal. The two stages are necessary to prevent met- 
astability, i.e., if the asynchronous signal transitions 
at or just before the clock transition, the output from 
the first flip-flop may not be stable. The second flip- 20 
flop allows an entire clock cycle for the first flip-flop's 
output to stabilize before passing the value of the sig- 
nal to its output. The synchronous state machine may 
then operate on the output of the second flip-flop on 
a next clock transition. Worse case, the asynchron- 25 
ous signal will transition just after the clock transition, 
and the first flip-flop will not pass the value on until 
the following clock transition. If this happens, then 
the synchronous state machine will not operate on 
the signal until a fourth clock transition. Accordingly, 30 
a problem with using a synchronous state machine to 
interface to an asynchronous bus is that it requires 
circuitry to synchronize the received asynchronous 
handshake signals. This circuitry or "synchronizer" in- 
troduces a high latency period between data being 35 
ready to transfer and data being transferred since the 
synchronizer invariably delays transitions of the asyn- 
chronous signals by up to three to four clock cycles. 

Another type of state machine is the asynchron- 
ous state machine. Asynchronous state machines are 40 
basically combinatorial circuits with feedback paths 
whose outputs depend upon the order in which its in- 
put variables change. Similar to the synchronous 
state machine, the combinatorial logic implements 
state equations which define the operation/flow of the 45 
state machine. However, there are no storage ele- 
ments, i.e., flip-flops, and, therefore, the outputs of 
the asynchronous state machine may be affected at 
any instant of time by changes in any inputs to the 
state machine. The combinatorial logic which com- so 
prises the asynchronous state machine generates 
the state bits and other output signals, and, therefore, 
changes from one state to the next are not controlled 
by a clock signal like the synchronous state machine. 
Thus, the asynchronous state machine changes 55 
states as fast as the combinatorial logic can operate 
on the received signals. In general, an asynchronous 
state machine interface to an asynchronous bus is 



much faster than the aforementioned synchronous 
state machine. To prevent glitches on state bits from 
forcing the asynchronous state machine into invalid 
states, only one state bit is permitted to change each 
time the state machine changes state. Therefore, only 
that state bit has the possibility of glitching and, thus, 
the asynchronous state machine will not transition to 
an incorrect state. In general, this leads to a large 
number of required states and, therefore, to a large 
number of state bits which increase the amount of cir- 
cuitry necessary to implement the state machine. 

Asynchronous state machines must also be de- 
signed to be hazard proof. A hazard may occur where 
inputs to the state machine are changing, and, thus, 
the state of the state machine is changing, but some 
outputs of the state machine are suppose to remain 
steady. In this case, as the state is changing, an out- 
put may momentarily change (i.e., glitch) to a different 
level than the steady value which may cause the 
state machine to improperly move to an incorrect 
state. To overcome this problem, the asynchronous 
state machine equations are provided with added 
terms, i.e., hazard terms, to prevent these possible 
glitches from causing transitions to wrong states. 
These added hazard terms further increase the 
amount of circuitry required to implement the asyn- 
chronous state machine. 

Accordingly, use of asynchronous interfaces to 
interface to an asynchronous bus is the preferred ap- 
proach if speed is a primary objective. However, as 
computer systems become more complex, bus Struc- 
tures associated with these systems become more 
complex. One problem with using an asynchronous 
interface to interface to such a complex bus, there- 
fore, is that the interface becomes correspondingly 
complex, and as the complexity of the bus structure 
increases, the size and cost of the interface increas- 
es concomitant therewith. 

In addition to the situation mentioned above, 
there are many other situations in which data must be 
transferred with an asynchronous bus. The above 
mentioned system bus may be synchronous or asyn- 
chronous. If the system bus is asynchronous, the dif- 
ficulties involved with interfacing to an asynchronous 
bus occur when interfacing to the system bus. 

SUMMARY OF THE INVENTION: 

The invention in its broad form resides in a data 
transfer device as recited in claim 1. The invention 
also resides in a data transfer network as recited in 
claim 18. 

As described herein, a data transfer device in- 
cludes means for controlling data transfer with an 
asynchronous bus. The means for controlling data 
transfer includes a synchronous logic network to pro- 
vide a transaction connection between the asyn- 
chronous bus and the data transfer device during an 
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initial phase of the transaction and an asynchronous 
logic network to provide data transfer between the 
asynchronous bus and the data transfer device during 
a subsequent phase of the transaction. With such an 
arrangement, the synchronous logic network can 5 
provide transaction control during a time when many 
determinations are required to be made by the data 
transfer device. Although the synchronous logic net- 
work may be slowerthan a corresponding asynchron- 
ous logic network, it is provided with significantly less 10 
circuitry than the asynchronous logic network. On 
the other hand, the asynchronous logic network pro- 
vides transaction control during a time when few de- 
terminations need to be made by the data transfer de- 
vice. Thus, while a corresponding synchronous logic 15 
network may be implemented in slightly less hard- 
ware than the asynchronous logic network, the syn- 
chronous logic network would be significantly slower 
than the asynchronous logic network. Therefore, a 
data transfer device is provided having a minimal 20 
amount of circuitry, while providing data transfer at a 
high rate of speed. 

In a modification described herein, a data transfer 
device includes means for interfacing to an asyn- 
chronous bus and means for controlling data transfer 25 
between the asynchronous bus interfacing means 
and the asynchronous bus. The means for controlling 
data transfer between the asynchronous bus interfac- 
ing means and the asynchronous bus includes, 
means for synchronously controlling an initial connec- 30 
tion phase of a transaction and means for asynchro- 
nously controlling a subsequent data transfer phase 
of the transaction. With such an arrangement, the 
synchronous controlling means provides transaction 
control during an initial connection phase when many 35 
determinations are required to be made by the data 
transfer device. The synchronous controlling means 
although typically slower than a corresponding asyn- 
chronous controlling means, is implemented with sig- 
nificantly less circuitry. On the other hand, the asyn- 40 
chronous controlling means provides transaction con- 
trol during a subsequent data transfer phase when 
few determinations need to be made by the data 
transfer device. Accordingly, the asynchronous con- 
trolling means is implemented in slightly less hard- 45 
ware than a corresponding synchronous controlling 
means and is correspondingly faster than a synchron- 
ous controlling means. Thus, a data transfer device is 
provided having a minimal amount of circuitry, while 
providing data transfer at a high rate of speed. so 

BRIEF DESCRIPTION OF THE DRAWINGS: 

A more detailed understanding of the invention 
can be had from the following description of a prefer- 55 
red embodiment, given by way of example only and to 
be understood in conjunction with the accompanying 
drawing wherein: 



FIG. 1 is a block diagram of a computer network 
having a system bus connected to an I/O bus by 
an I/O device in accordance with an embodiment 
of the invention; 

FIG. 2 is a more detailed block diagram of the I/O 
device of FIG. 1; 

FIG. 3 is a more detailed block diagram of the 
slave controller of FIG. 2 in accordance with an 
embodiment of the invention; 
FIG. 4 is a state diagram illustrating the flow of 
the first synchronous state machine of FIG. 3; 
FIG. 5 is a state diagram illustrating the flow of 
the first asynchronous state machine of FIG. 3; 
FIG. 6 is a truth table illustrating the operation of 
the first asynchronous state machine of FIG. 3; 
FIG. 7 is a Karnaugh map illustrating the condi- 
tions under which a specific output signal dis- 
played in the truth table of FIG. 6 is asserted; 
FIG. 8 is a state diagram illustrating the flow of 
the second synchronous state machine of FIG. 3; 
and 

FIG. 9 is a state diagram illustrating the flow of 
the second asynchronous state machine of FIG. 
3. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS: 

As noted above, this invention involves a method 
and apparatus for transferring data to and receiving 
data from an asynchronous system such as an asyn- 
chronous bus. An interface apparatus to the asyn- 
chronous bus is divided into a synchronous section 
and an asynchronous section. An initial portion of a 
transaction on the asynchronous bus is controlled by 
the synchronous section while a subsequent data 
transfer portion of the transaction is controlled by the 
asynchronous section. This reduces the amount of 
circuitry required to provide the interface apparatus 
while providing for fast data transfer with the asyn- 
chronous bus through the interface apparatus. 

Referring now to FIG. 1, a computer network 10 
is shown to include a computer system 12 which in- 
cludes a central processing unit (CPU) 12a, a main 
memory module 12b, and an input/output (I/O) device 
12c coupled together by a system bus 12d. There 
may be multiple CPUs, main memory modules, and 
I/O devices resident on the system bus, although only 
one of each is shown in FIG. 1 for simplicity. The com- 
puter network 10 further includes an I/O bus 13 used 
to couple the computer system to a peripheral device 
14, a second computer system 16 which may be the 
same type of system as computer system 12 or may 
be a different type of computer system, and a bus in- 
terface 18. Examples of peripheral devices which 
may be coupled to the bus 13 include, tape drives, 
disk drives, printers, etc. There may be multiple per- 
ipherals, computer systems, and bus interfaces, i.e., 
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devices designed to transfer data between at least 
two busses, resident on the I/O bus, although only 
one of each is shown in FIG. 1 for simplicity. Here 
each of the devices 14, 16, and 18 have correspond- 
ing interface apparatus 14a, 16a, and 18a, as shown, 5 
to interface the respective device to the I/O bus 13. 
As also shown, bus interface device 18 is disposed to 
interface I/O bus 13 to a third bus 19 which may be a 
computer system bus (as bus 12d) or another net- 
work bus (as bus 13). w 

The I/O device 12c is provided to accommodate 
the transfer of data between the I/O bus 13 and the 
system bus 12d. In this example, the system bus 12d 
and the devices resident on the system bus operate 
synchronous to a common clock signal, while the I/O 15 
bus 13 and the devices resident on the I/O bus oper- 
ate asynchronously. Accordingly, the I/O device 12c 
is used to transfer data between the synchronous 
computer system and the asynchronous I/O bus. 

Often, the I/O bus 13 couples together devices 20 
which may have different characteristics. A flexible 
protocol, i.e., a predetermined bus control technique 
through which data may be transferred over the bus, 
on the I/O bus 13 is here implemented to accommo- 
date various characteristics of different devices cou- 25 
pled to bus 1 3, and allow such devices to operate op- 
timally. An example of a flexible protocol for the I/O 
bus 13 is the so called ,, Futurebus+ ,, (FBUS) protocol 
as set forth in specifications provided by the Institute 
for Electrical and Electronic Engineers, including 30 
IEEESTD. 896.1 - 1991: Logical Layer Specification. 
As an illustrative example, the I/O device 12c will be 
described with respect to interfacing to an I/O bus 13 
implementing the FBUS protocol. It will be appreciat- 
ed, however, that I/O device 12c has applicability to 35 
other types of busses and that description of the 
FBUS is illustrative of one preferred embodiment of 
the invention. A brief description of the FBUS will first 
be given before proceeding further. 

The FBUS is a low assertion bus, (i.e., an assert- 40 
ed signal is at a lower voltage level than a deasserted 
signal). Often the system bus 12d is a high assertion 
bus, (i.e., an asserted signal is at a higher voltage lev- 
el than a deasserted signal). The I/O device 12c must 
respond correctly to the assertion levels of each. 45 
Hereinafter, asserted and deasserted refer to the ap- 
propriate assertion and deassertion logic levels for 
the respective bus. 

When a device, such as the I/O device 12c, per- 
ipheral 14, computer system 16, and bus interface 18, so 
shown in FIG. 1 , engage in a transaction using the bus 
1 3, the devices gain control of the bus through a proc- 
ess known as "arbitration". Arbitration is one step in 
implementing a protocol in which a device called an 
FBUS master device is chosen from among compet- 55 
ing devices for use of the bus 1 3 for a given period of 
time referred to as a "transaction". The bus master de- 
vice is one of the devices involved in a transaction and 



is selected by an arbiter (not shown). There are many 
different types of arbitration techniques known in the 
art The FBUS employs a central arbiter (not shown) 
to which all devices on the FBUS wanting to gain con- 
trol of the FBUS, i.e., become an FBUS master de- 
vice, send a bus request signal. The central arbiter 
grants control of the FBUS to one of the devices 
which sent a bus request signal, according to a pre- 
determined scheme which distributes such control 
among the various devices which desire to gain ac- 
cess to the bus. Schemes which are implemented by 
the arbiter include, priority schemes, round-robin 
schemes, and so forth. Typically, when a device is is- 
sued a grant from the arbiter, it gains the status of bus 
master elect. The device will actually exercise control, 
i.e., become the bus master device, when any current 
transaction on the bus is completed. 

Once a device gains control of the bus, i.e., be- 
comes a bus master device, the bus master device 
sends address and command information onto appro- 
priate bus lines to begin a connection phase. Descri- 
bed below are some of the standard signals imple- 
mented by the FBUS. These signals will be described 
below, in conjunction with FIG.s 1 - 2. For FBUS 13, 
the address is here placed on FBUS address/data 
lines (AD) sixty-three to zero, i.e., AD<63:0>, and the 
command is placed on FBUS command lines (CM) 
seven to zero, i.e., CM<7:0>. The command lines in 
the connection phase indicate which AD lines contain 
valid data, i.e., AD<31:0> and possibly AD<63:32>. 
After asserting the appropriate command and ad- 
dress bits, the FBUS master device will assert an ad- 
dress synchronization handshake signal, i.e., FB_AS, 
to indicate that the bus lines contain valid data and 
that all modules resident on the bus should examine 
the data. The devices on the bus respond by assert- 
ing an address acknowledge signal, i.e., FB_AK, cap- 
turing the address and command information on the 
bus. The bus slave device immediately asserts a data 
acknowledge inverse handshake signal, i.e., FB_DI, 
for later use. The responding devices decode the ad- 
dress to determine if they are a target of the transac- 
tion, i.e., a bus slave device, and decode the com- 
mand to determine what type of transaction has been 
initiated. The devices also check for parity and other 
errors. For example, if a command when decoded is 
determined to be for a transaction which the bus slave 
device is incapable of handling, an error is signaled. 

The FBUS provides eight status lines (ST), i.e., 
ST<7:0>, for responding devices to use to notify the 
bus master device of significant events, such as, that 
they are a target of the transaction or that there are 
errors, etc. Once the address has been decoded, at 
least one device has determined that it is a target, i.e., 
bus slave device, of the transaction, or there are er- 
rors. The bus slave device asserts the appropriate 
status line on the FBUS and when the device is pre- 
pared to continue to the next phase of the transaction, 
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the device deasserts an address acknowledge in- 
verse handshake signal, i.e., FB_AI. All devices, in- 
cluding those which are not a target of the transac- 
tion, deassert the FB_AI signal as a confirmation to 
the bus master device that they have decoded the ad- 5 
dress and checked for errors. 

Following the deassertion by all devices on the 
bus of the FB_AI signal, the bus master device may 
proceed to the data transfer phase. At the beginning 
of the data phase, the bus master device may provide 10 
information through the command lines to the bus 
slave device as to the amount of data which will be 
transferred in the current transaction. Data may be 
transferred between the bus master device and the 
bus slave device over the AD<63:0> lines and data 15 
lines two hundred and fifty-five to sixty-four, i.e., 
D<255:64>. The command information sent by the 
bus master device in the connection phase will indi- 
cate which of the available lines, i.e., the data width, 
will contain valid data, i.e., AD<31:0> and possibly 20 
AD<63:32>, D<127:64>, and D<255:128> ( and 
whether the transaction is to transfer data to the bus 
slave device, i.e., write, or request data from the bus 
slave device, i.e., read. If the transaction is a write, 
the bus master device places the data to be transfer- 25 
red on the appropriate bus lines upon detecting the 
deassertion of the FB_AI signal and asserts a data 
synchronization handshake signal, i.e., FB_DS. If the 
transaction is a read, the bus master device imme- 
diately deasserts the address and asserts the 30 
FB_DS signal upon detecting the deassertion of the 
FB_AI signal. Upon detecting the assertion of the 
FB_DS signal, for a read or a write, the bus slave de- 
vice responds immediately by asserting a data ac- 
knowledge handshake signal, i.e., FBJDK, for later 35 
use. In the case of a read, the bus slave device then 
prepares to place data on the bus, and if the bus mas- 
ter device provided information as to the amount of 
data which is to be transferred, the bus slave device 
may use this information to more efficiently transfer 40 
the data from main memory 12b (FIG. 1) to the bus 
master device. 

After the bus slave device has captured data on 
the bus lines (a write operation from the bus master 
device), or placed data onto the bus lines (a read op- 45 
eration from the bus master device), the bus slave de- 
vice deasserts the FB_Dl signal. This indicates to the 
bus master device that the bus slave device has re- 
moved data from or provided data onto the bus and 
has also provided status, i.e., ST<7:0>, onto the bus. so 
The bus master device then provides more data (for 
a write) or captures the data sent by the bus slave de- 
vice (for a read), and captures the status sent by the 
bus slave device. When the bus master device is 
ready forthe next data transfer, the bus masterdevice 55 
deasserts the FB_DS signal. Both the asserting edge 
and deasserting edge of the FB_DS signal are used 
to transfer data. The asserting edge of the FB_DS sig- 



nal signifies the beginning of an "odd data beat", 
while the deasserting edge of the FB_DS signal sig- 
nifies the beginning of an "even data beat". The bus 
slave device responds to the deassertion of the 
FB_DS signal immediately with the re-assertion of 
the FB_DI signal, for later use. When the bus slave 
device has again removed data or provided data, and 
provided status, the bus slave device deasserts the 
FB_DK signal. The deassertion of the FB_DK signal 
indicates that the bus slave device has completed the 
even data beat, i.e., the bus slave device has either 
removed data or provided data, and provided status 
(the earlier deassertion of the FB_DI signal indicates 
that the bus slave device completed the odd data 
beat). 

In general, a plurality of such data beats occur in 
a similar way as outlined above. When the bus master 
device is done sending or receiving data, the bus 
master device deasserts the FB_AS signal and en- 
ters the disconnection phase. The bus slave device 
immediately asserts the FB_AI signal and then deas- 
serts the FB_DI signal and the FB_DK signal as nec- 
essary depending on whether the last data transfer 
was an even or an odd data beat. The bus master de- 
vice then deasserts the FB_DS signal if the last data 
transfer was an odd data beat. Following this, the bus 
slave device asserts any appropriate status and in 
certain situations captures information from the data 
lines sent by the bus master device and then deas- 
serts the FB_AK signal. The bus masterdevice then 
captures the status and the transaction is ended. 

Flexible protocols allow for many devices, having 
different capabilities, to transfer data with each other. 
However, this flexibility generally adds complexity. 
Sophisticated devices may be allowed to transfer data 
with similarly sophisticated devices or with less so- 
phisticated devices. At the beginning of a transaction 
many determinations need to be made about the 
transaction which is to be carried out and about how 
the transaction is to be carried out. These determina- 
tions take time and may require the bus master device 
or the bus slave device to respond in certain ways. In 
the case of the FBUS, most of these determinations 
are made in the connection phase, while the subse- 
quent data phase requires relatively few determina- 
tions at the beginning of the data phase. One deter- 
mination forthe FBUS is the type of transaction to be 
carried out, for example, read, write, partial, split, etc. 
All these transactions are described in detail in the 
IEEE Std. 896.1 - 1991. Other determinations include 
which address lines are to be used, which data lines 
are to be used, how much data is to be transferred, 
etc. Each determination requires the bus master de- 
vice and the bus slave device to operate differently. 

Referring now to FIG. 2, the I/O device 1 2c is cou- 
pled to the asynchronous I/O bus 13 through an asyn- 
chronous bus interface 20. The asynchronous bus in- 
terface 20 includes conventional interface circuits 22, 
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24, 26, 27, and 28 dedicated to the address 22 
(AD<63:0>), handshake 24 (FB_AS, FB_DS, FB_AI, 
FB_AK, FB_DI, FB_DK) f status 26 (ST<7:0>), com- 
mand 27 (CM<7:0>), and data 28 (D<255:64>) sig- 
nals on the asynchronous bus. This circuitry includes 5 
line terminations (not shown) for maintaining the ap- 
propriate signal integrity on the asynchronous bus by 
providing an appropriate matching impedance termin- 
ation, and buffers (not shown) for providing appropri- 
ate voltage level translation between voltage levels of 10 
signals on the asynchronous bus and voltage levels 
of signals on the remainder of the I/O device 12c. The 
asynchronous bus interface 20 also includes trans- 
ceivers (not shown) for sending and receiving data, 
and combinatorial logic (not shown) for decoding re- 15 
ceived signals or encoding signals to be sent. 

The I/O device 12c further includes a slave con- 
troller 32 and a master controller 34 coupled to the 
asynchronous I/O bus 13 through the asynchronous 
bus interface 20. The I/O device 1 2c furt her includes 20 
synchronizer logic circuit 36 which is coupled be- 
tween the controllers 32, 34 and the handshake cir- 
cuitry 24 of the asynchronous bus interface 20. The 
synchronizer logic 36 includes conventional dual 
stage synchronizers (not shown), as previously dis- 25 
cussed, for synchronizing each received signal. An 
oscillator 38 is also a part of the I/O device 12c and 
provides a CLK signal 38a to the synchronizer logic 
36 and the slave controller 32. The CLK signal 38a 
may also be used by other components of the I/O de- 30 
vice 12c (not shown), and instead of being supplied 
from oscillator 38, the CLK signal 38a may be provid- 
ed by the system bus 12d, where the system bus 12d 
is a synchronous bus. The controllers 32, 34 receive 
asynchronous handshake signals directly from the 35 
handshake circuitry 24 and synchronized handshake 
signals from synchronizer logic 36. The slave control- 
ler 32 responds to transactions initiated by other de- 
vices resident on the asynchronous I/O bus 13, while 
the master controller 34 initiates transactions on the 40 
asynchronous I/O bus 13. 

As shown in FIG. 2, both controllers 32, 34 are 
further coupled to a gate array 40. The gate array 40 
includes combinatorial logic arranged to provide inter 
alia a bank of data buffers including data buffer 42a 45 
and data buffer 42b, control logic 44, and a system 
bus interface 46. There may be more than two data 
buffers in the bank of data buffers 42a, 42b, however, 
only two are shown in FIG. 2 for simplicity. Through 
the gate array 40, the controllers 32, 34 are coupled so 
to the system bus 12d and may transfer data to and 
receive data from devices such as CPU 12a or main 
memory 12b resident on the system bus (FIG. 1). 

Referring now to FIG. 3, the slave controller 32 is 
shown to include here delay logic 48 and four state 55 
machines 50 - 53; a first synchronous state machine 
50, a first asynchronous state machine 51, a second 
synchronous state machine 52, and a second asyn- 



chronous state machine 53. The delay logic 48 con- 
tains delay circuitry, including conventional delay ele- 
ments and combinatorial logic. Through the delay log- 
ic 48, signals may be delayed by predetermined or 
varying periods of time. The state machines 50 - 53 
are logic circuits which implement particular state 
equations. Often, programmable array logic (PAL) 
components are used as they are well suited for the 
implementation of state machines. Both synchronous 
state machines 50, 52 are synchronous to the CLK 
signal 38a and will change states when an appropri- 
ate state equation is true (combinatorial logic), and 
the CLK signal 38a transitions (flip-flop storage ele- 
ments). As previously mentioned, the CLK signal 38a 
may come from the synchronous system bus and, 
therefore, the synchronous state machines 50, 52 
would be synchronous to the system bus, or the CLK 
sig nal 38a may come from t he oscillator 38. If t he CLK 
signal comes from the oscillator 38, the period of the 
CLK signal may be chosen to be a derivative of the 
period of the system bus clock which allows the syn- 
chronous state machine 50, 52 to operate more effi- 
ciently than the period of the system bus clock signal. 
Both asynchronous state machines 51, 53 will change 
states (only one state bit will transition for each state 
change) when an appropriate state equation, includ- 
ing hazard terms, is true (combinatorial logic). These 
four state machines are used to respond to transac- 
tions initiated on the asynchronous I/O bus 13. 

As shown in FIG. 3, the first synchronous state 
machine 50 receives a line carrying the CLK signal 
38a and a line carrying a data buffer available signal 
44a, i.e., BUFFER_AVAILABLE. The BUF- 
FER_AVAILABLE signal 44a may be one signal or a 
set of data buffer status signals from the control logic 
44 in gate array 40 (FIG. 2). The first synchronous 
state machine 50 also receives a line carrying a mas- 
ter signal 34a, i.e., MASTER, from the master control- 
ler 34 (FIG. 1), and lines carrying the synchronized 
address handshake signal 36a and the data hand- 
shake signal 36b, i.e., SYNCH_AS and SYNCH J)S, 
respectively, from the synchronizer logic 36 (FIG. 2). 
The asynchronous interface 20 handshake circuitry 
24 sends received versions of asynchronous bus 
handshake signals to the synchronizer logic 36 
(FIG.2). For example, the FB_AS and FBJ)S signals 
from the asynchronous I/O bus are coupled to the 
handshake circuitry 24 which sends received ver- 
sions of these signals 24a and 24b, i.e., FB_R_AS 
and FB_R_DS, respectively, to the synchronizer logic 
36 (FIG. 2). The first synchronous state machine 50 
also receives decode signals from the asynchronous 
bus interface 20 (FIG.2). The first synchronous state 
machine receives a decode line carrying a signal 22a 
from the address circuitry 22 indicating whether the 
I/O device 12c is a bus slave device, i.e., SLAVE. The 
first synchronous state machine also receives decode 
lines carrying signals 27a and 27b from the command 
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circuitry 27 indicating the type of transaction, i.e., 
PARTIAL and SPLIT_RESP, respectively. The first 
synchronous state machine 50 uses these signals to 
determine when another device on the asynchronous 
I/O bus 13 (FIG.1) is initiating a transaction. 5 

Also, as shown in FIG. 3, the first synchronous 
state machine 50 provides a line carrying a data buf- 
fer address strobe signal 50a, i.e., BUFFER_AS, 
which is received by the control logic 44 in gate ar- 
ray 40 (FIG. 2). The first synchronous state ma- 10 
chine 50 also provides a line carrying signal 50b, 
i.e., NO_CONN_HOLD, which is received by the first 
asynchronous state machine 51 and a line carrying 
signal 50c, i.e., GO, which is received by the second 
synchronous state machine 52. The first synchronous 15 
state machine 50 also provides lines carrying signals 
50d and 50e, i.e., MBX_SEL and LT_MASK, respec- 
tively, necessary for certain transactions which will be 
described in more detail later. These signals allow- 
the first synchronous state machine 50 to hold off the 20 
first asynchronous state machine 51 until the address 
and command information provided by the bus mas- 
ter device has been captured and decoded to deter- 
mine whet her the I/O device is a bus slave device and 
whether there are any errors, such that the I/O device 25 
may provide the appropriate connection phase status 
on the ST<7:0> lines of the asynchronous bus. The 
first synchronous state machine 50 also holds off the 
second synchronous state machine 52 until the type 
of transaction has been determined and thus, the first 30 
synchronous state machine asserts the GO signal 
50c. 

The BUFFER_AVAILABLE signal 44a from the 
control logic 44 in the gate array 40 indicates that a 
data buffer in the bank of data buffers 42a, 42b of the 35 
gate array 40 (FIG. 2) is available. Alternatively, the 
slave controller 32 could keep track of the number of 
data buffers and their availability with additional cir- 
cuitry (not shown) using additional other signals (not 
shown) from the gate array. This example locates this 40 
buffer availability circuitry in the gate array, and thus, 
centralizes the circuitry for both the master and slave 
controllers 32, 34, respectively. The large amount of 
circuitry available in a gate array may allow for more 
flexibility. For example, the circuitry in the gate array 45 
may be able to provide more easily for dynamically 
changing the size of the data buffers, etc. The term 
"available" as used here indicates that a data buffer 
is empty so that it may accept data from the asyn- 
chronous I/O bus in the case of an asynchronous I/O so 
bus write received from a bus master device or that it 
may accept data from the synchronous system bus in 
the case of an asynchronous I/O bus read received 
from a bus master device. 

The MASTER signal 34a is asserted by the mas- 55 
ter controller 34 when the master controller is initiat- 
ing a transaction on the asynchronous I/O bus 13 
(FIG.s 1 and 2). The SYNCH_AS signal 36a and 



SYNCH_DS signal 36b are synchronized versions of 
the received asynchronous I/O bus address and data 
handshake signals 24a and 24b, i.e., FB_R_AS and 
FB_R_DS, respectively. The SLAVE signal 22a indi- 
cates whether the I/O device 12c (FIG. 1) is a bus 
slave device, and the PARTIAL signal 27a and 
SPLIT_RESP signal 27b indicate what type of trans- 
action has been initiated. 

The BUFFER_AS signal 50a may be asserted by 
the first synchronous state machine 50 to cause con- 
trol logic 44 in gate array 40 (FIG. 2) to use the ad- 
dress and command signals which were captured by 
the asynchronous bus interface 20 address circuitry 
22 and command circuitry 27 (FIG. 2). In the case of 
a write, the address and command is used by the gate 
array control logic to store data received from the bus 
master device in the bank of data buffers 42a, 42b of 
the gate array, and then the control logic uses the ad- 
dress to transfer the data from the bank of data buf- 
fers to the main memory 12b on the system bus 12d 
(FIG. 1). In the case of a read, the address informa- 
tion is used by the gate array control logic to transfer 
the necessary data from the main memory on the 
system bus to the bank of data buffers of the gate ar- 
ray, and then the control logic uses the address and 
command information to transfer the data from the 
bank of data buffers to the asynchronous I/O bus. 

The assertion of the NO_CONN_HOLD signal 
50b indicates to the first asynchronous state machine 
51 that another device on the asynchronous I/O bus 
is initiating a transaction, that the address and com- 
mand information on the asynchronous I/O bus has 
been captured and at least partially decoded such 
that the appropriate connection phase status has 
been placed on the ST<7:0> lines of the asynchron- 
ous I/O bus, and that a data buffer in the bank of data 
buffers 42a, 42b of the gate array is available for the 
transaction. 

In the state diagrams of FIG.S 4, 8, and 9, ovals 
represent states and arrows leading into and out of 
ovals represent paths that may be taken by the state 
machine from one state to another. An arrow leading 
out of an oval and back into the same oval indicates 
a looping condition where the state machine remains 
in that state until a state equation becomes true which 
allows the state machine to transition to a next state. 
Asterisks (*) to the left of signals which are adjacent 
arrows leading from one oval into another oval indi- 
cate that these are output signals of the state ma- 
chine. Up and down arrows to the right of output sig- 
nals represent the assertion or deassertion, respec- 
tively, of the state machine output signal when the 
state machine transitions from one oval to another 
oval. The synchronous state machines 50 and 52 are 
here implemented using conventional D-type flip- 
flops, and, therefore, output signals of the state ma- 
chine which are shown asserted upon entry into one 
state will automatically deassert if not shown assert- 
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ed in the next state. Equations adjacent arrows lead- 
ing from one oval into another oval represent at least 
a portion of the state equation required to be met in 
order to enter the oval, i.e., state, into which the arrow 
leads. Both asynchronous state machines 51 and 53 5 
may further include hazard terms in their state equa- 
tions which have not been included in the state dia- 
grams for simplicity. Within the state equations, AND 
represents the basic boolean algebra "and" function, 
OR represents the basic boolean algebra "or" tunc- w 
tion, and NOT represents the basic boolean algebra 
complement function. An arrow leading from an oval 
into a circle with a number inside corresponds to at 
least one other circle with the same number inside 
having an arrow leading into another oval. These cir- 15 
cles with the same number inside represent connec- 
tions as if each oval having an arrow leading into a cir- 
cle with a number inside had an arrow leading directly 
into the oval which receives an arrow from a circle 
containing the same number. The state diagrams use 20 
these circles to simplify the drawings. 

Referring now to FIG. 4, a state diagram illustrat- 
ing the operation of the first synchronous state ma- 
chine 51 of FIG. 3 is shown. The first synchronous 
state machine 51 begins in an ldle__50 state and tran- 25 
sitions to a Wait_1 state when the state equation: 
BUFFERjWAILABLE 44a AND (NOT MASTER 34a) 
AND SYNCH_AS 36a, becomes valid, (i.e., the BUF- 
FERJWAILABLE signal 44a and SYNCH_AS signal 
36a are asserted and the MASTER signal 34a is 30 
deasserted). These signals indicate that a transac- 
tion has been initiated on the asynchronous I/O bus, 
that the I/O device is not initiating the transaction, and 
that a data buffer in the bank of data buffers 42a, 42b 
of the gate array 40 (FIG. 2) is available. 35 

If this first state equation is valid, the state ma- 
chine transitions to the Wait_1 state on the next tran- 
sition of the CLK signal 38a, and asserts the BUF- 
FER_AS signal 50a. There is no state equation for the 
WaiM state, and, therefore, on the next transition of 40 
the CLK signal 38a, the state machine will automati- 
cally transition to a Wait_2 state. The state machine 
will similarly remain in the Wait_2 state for one tran- 
sition of the CLK signal and continue to assert the 
BUFFER_AS signal 50a. The states WaiM and 45 
Wait_2 are termed "wait" states, as they are used to 
add clock cycle delays into the operation of the state 
machine. The number of wait states can vary depend- 
ing on particular characteristics of the bus and inter- 
face apparatus coupled to the bus. The number of so 
wait states is chosen in this instance to be greater 
than or equal to the period of time necessary for the 
asynchronous bus interface 20 address circuitry 22 
and command circuitry 27 (FIG. 2) to capture and at 
least partially decode the address and command sig- 55 
nals received from the asynchronous I/O bus such 
that the error circuitry (not shown) may determine if 
an error has occurred and the address circuitry 22 



may determine whether the I/O device is a bus slave 
device. The period of time is sufficient to allow the I/O 
device to determine the necessary status information 
and place the status information on the ST<7:0> 
lines, and for the control logic 44 in gate array 40 
(FIG. 2) to use the address information. 

From the Wait_2 state, the first synchronous 
state machine 50 transitions to a Conn_Hnd state 
where it asserts the NO_CONNJHOLD signal 50b to 
the first asynchronous state machine 51 (FIG. 3). The 
assertion of the NO_CONN_HOLD signal 50b allows 
the first asynchronous state machine 51 to respond 
on the asynchronous I/O bus with the connection 
phase handshake signals, which will be described in 
more detail later. The first synchronous state machine 
50 then examines the SLAVE signal 22a, the PAR- 
TIAL signal 27a, and the SPLIT_RESP signal 27b. 
The PARTIAL signal 27a and the SPLIT_RESP signal 
27b indicate two types of transactions which will be 
described in more detail later. The SLAVE signal 22a 
indicates that the I/O device is a target of the current 
transaction. If the SLAVE signal 22a is deasserted, 
i.e., NOT SLAVE 22a, then the I/O device is not the 
target of the transaction, and a Not__Slave state is en- 
tered. The state machine remains in the Not_Slave 
state until the transaction is finished, signified by the 
deassertion of the SYNCH_AS signal 36a. When the 
SYNCH_AS signal 36a deasserts, the first synchron- 
ous state machine 50 enters the ldle_50 state and as- 
serts the NO_CONN_HOLD signal 50b to the first 
asynchronous state machine 51, to allow the first 
asynchronous state machine 51 to handle the discon- 
nection phase handshake signals which will be de- 
scribed in more detail later. 

If the SLAVE signal 22a is asserted and the PAR- 
TIAL signal 27a and the SPLIT_RESP signal 27b are 
deasserted, i.e., SLAVE 22a AND (NOT PARTIAL 
27a) AND (NOT SPLIT.RESP 27b), the transaction is 
a simple data transfer. Therefore, the first synchron- 
ous state machine 50 transitions to a Strt_Data state 
and asserts the GO signal 50c to the second syn- 
chronous state machine 52 to begin the data transfer 
phase, to be described in more detail later. The first 
synchronous state machine 50 then remains in the 
Strt_Data state until the transaction is ended which is 
indicated by the deassertion of the SYNCH_AS sig- 
nal 36a. Upon the deassertion of the SYNCH_AS sig- 
nal 36a, the state machine returns to the ldle_50 state 
to wait for the initiation of another transaction and as- 
serts the NO_CONN_HOLD signal 50b. 

If necessary, the first synchronous state machine 
50 could add wait states to delay the assertion of the 
NO_CONN_HOLD signal 50b following the deasser- 
tion of the SYNCH_AS signal 36a. For example, a bus 
slave device which is splitting a transaction (to be de- 
scribed in more detail later) must capture the bus 
master device's disconnection identification in the 
disconnection phase which the bus master device 
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places on the data lines. The bus slave device may 
need additional time to capture this information than 
is required in the disconnection phase of a completed 
transaction, and the first synchronous state machine 
50 could provide the additional time by adding wait 5 
states following the deassertion of the SYNCH_AS 
signal 36a. An additional path in the first synchronous 
state machine 50 could be added to handle this situa- 
tion so that other transactions are not unnecessarily 
delayed. 10 

During the operation of the first synchronous 
state machine 50, the assertion of the PARTIAL sig- 
nal 27a indicates that out of the available lines chos- 
en for data transfer, i.e., the AD<31:0> lines and pos- 
sibly the AD<63:32>, D<255;128>, and D<127:64> is 
lines, only certain groups of eight lines, for example, 
AD<7:0> and AD<31 :24> from AD<31 :0>, will contain 
valid data. The first data transfer in a partial transac- 
tion contains data which are used as a data transfer 
mask. The mask is saved in circuitry, such as a reg- 20 
ister (not shown), and used during the transaction for 
subsequent data transfers. The mask is thirty-two 
bits wide with each bit corresponding to a group of 
eight lines (a byte of data). For example, mask bit zero 
corresponds to lines AD<7:0>, while mask bit thirty- 25 
one corresponds to lines D<255:248>. A convention 
is established to indicate when a particular group of 
lines, i.e., AD<7:0>...D<255:248>, contain a valid 
byte of data. The convention used here is that if mask 
bit zero is a logic level one, "1", the corresponding 30 
lines, i.e : , AD<7:0>, will contain valid data. If mask bit 
zero is a logic level zero, "0", the data is not valid. 

The assertion of the SPLIT_RESP signal 27b in- 
dicates that the bus master device is initiating a split 
response transaction. A split response transaction is 35 
one in which the current bus master device, is re- 
sponding to an earlier transaction which was initiated 
by another device, i.e., the original bus master de- 
vice, now the current bus slave device. For example, 
an original bus slave device may determine that a 40 
considerable amount of time is required to retrieve 
data necessary to service a read request by an orig- 
inal bus master device. In such a case, the original 
bus slave device may split, i.e., end, the transaction 
before the data transfer phase such that other devic- 45 
es on the asynchronous I/O bus may conduct trans- 
actions while the original bus slave device retrieves 
the requested data. When the original bus slave de- 
vice has retrieved the requested data, it may continue 
the transaction by initiating, i.e., becoming the bus 50 
master device, a split response transaction, and send- 
ing the requested data to a current bus slave device, 
i.e., the original bus master device. 

Both a partial and a split response transaction re- 
quire additional actions to those required for a simple 55 
read or write. The state machine handles these addi- 
tional actions through additional states. In the first 
synchronous state machine, if the PARTIAL signal 



27a and the SLAVE signal 22a are asserted, i.e., 
SLAVE 22a AND PARTIAL 27a, during the Conn_Hnd 
state, the state machine proceeds to a Partial state 
and waits for the assertion of the SYNCH_DS signal 
36b from the synchronizer logic 28 (FIG. 2). If the 
SYNCH_AS signal 36a deasserts while in the Partial 
state, i.e., NOT SYNCH_AS, before the assertion of 
the SYNCH_DS signal 36b, then the transaction 
has ended, and the state machine asserts the 
NO_CONN_HOLD signal 50b and enters the ldle_50 
state to wait for the initiation of another transaction on 
the asynchronous I/O bus. However, upon the asser- 
tion of the SYNCH_DS signal 36b while the state ma- 
chine is in the Partial state, the first synchronous 
state machine 50 transitions to a Lt_Mask state and 
asserts the LT_MASK signal 50e. The LT_MASK sig- 
nal 50e causes the byte mask register circuitry (not 
shown) to latch the byte mask data. The LT_MASK 
signal 50e is also sent to the second asynchronous 
state machine 53 to enable the second asynchronous 
state machine 53 to respond on the asynchronous I/O 
bus with the appropriate data phase handshake sig- 
nals, to be described in more detail later. When the 
state equation: SYNCH_AS 36a and (NOT 
SYNCH_DS 36b), becomes valid, the state machine 
then transitions to a Wait_3 state. Several wait states 
may be added between the Lt_Mask state and the 
Wait_3 state in order to set up the circuitry required 
to accomplish a partial transaction. When the circui- 
try is ready and the mask data has been captured, the 
first synchronous state machine 50 transitions to the 
Strt_Data state and asserts the GO signal 50c. 

In the first synchronous state machine 50, if the 
SPLIT_RESP signal 27b and the SLAVE signal 22a 
are asserted and the PARTIAL signal 27a is deassert- 
ed, i.e., SLAVE 22a AND (NOT PARTIAL 27a) AND 
SPLIT_RESP 27b, during the ConnJ-Ind state, the 
state machine proceeds to a Split state and asserts 
the MBX.SEL signal 50d. The MBX_SEL signal 50d 
is used by circuitry (not shown) to resume the proc- 
essing of a previously split transaction. Any number of 
wait states, i.e., Wait_4 state, may be added to allow 
sufficient time to prepare such circuitry. When the cir- 
cuitry is prepared to respond to the split response 
transaction, the first synchronous state machine 50 
transitions to the Strt_Data state and asserts the GO 
signal 50c. 

The above outlined state machine includes some 
of the many determinations that need to be made 
when the I/O device 12c (FIG. 1 ) is a bus slave device. 
There can be many other determinations which are 
made in the connection phase of a transaction, such 
as determinations depending upon the characteris- 
tics of the I/O device 12c, the bus master device, and 
the asynchronous I/O bus 13. For example, the I/O 
device 12c may initiate a split transaction as descri- 
bed above. 

Implementing the protocol of the connection 
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phase as the first synchronous state machine 50 pro- 
vides a slower state machine than if the protocol were 
implemented as a corresponding asynchronous state 
machine due to the necessity of synchronizing the 
FB_R_AS signal 24a, i.e., the SYNCH_AS signal 5 
36a, and the FB_R_DS signal 24b, i.e., the 
SYNCH_DS signal 36b, (FIG. 2) as previously dis- 
cussed. The first synchronous state machine 50 may 
also be slower than a corresponding asynchronous 
state machine, because the synchronous state ma- w 
chine will not change state until the appropriate state 
equation is true and the CLK signal 38a transitions, 
whereas a corresponding asynchronous state ma- 
chine will change state as soon as the appropriate 
state equation becomes true. 15 

However, an I/O device used to interface to an 
asynchronous bus implementing a flexible protocol 
which allows a large number of different devices to 
operate optimally, such as the FBUS, requires that 
I/O device to make many determinations, including 20 
whether the I/O device is a bus slave device, what 
type of transaction has been initiated, and how that 
transaction is to be handled. After these many deter- 
minations are made, the I/O device may need to re- 
spond in correspondingly different ways. These dif- 25 
ferent responses may be handled by different paths 
in a state machine of the I/O device. As mentioned 
previously, asynchronous state machines allow only 
one state bit to change per state transition. Therefore, 
synchronous state machines such as the first syn- 30 
chronous state machine 50 are generally better suited 
than asynchronous state machines for implementing 
different paths from one state into many other states 
due in part to the fact that synchronous state ma- 
chines are not limited to allowing only one state bit to 35 
change per state transition. Further, a synchronous 
state machine also allows wait states to be easily add- 
ed, i.e., no additional circuitry, to the many paths that 
may be required of the state machine to allow suffi- 
cient time for specific circuitry to be set up or for sig- 40 
nals to propagate through specific circuitry. 

For an asynchronous state machine to add a wait 
state additional circuitry would need to be added, for 
example, delay logic to delay a previous signal. Also, 
as the number of states increases in an asynchronous 45 
state machine, the number of state bits significantly 
increase due to the necessity of allowing only one 
state bit to change per state transition (a correspond- 
ing synchronous state machine may require less state 
bits). The number of hazard terms required for an so 
asynchronous state machine will also increase as the 
number of state bits and input signals increase. If the 
protocol of the connection phase is implemented as 
a corresponding asynchronous state machine, the 
corresponding asynchronous state machine would, in 55 
general, be very large requiring significantly more cir- 
cuitry than the first synchronous state machine 50 
due to the requirement of having only one state bit 



change per state transition and also due to the nec- 
essity of including hazard terms in the state equa- 
tions, as previously discussed. 

Moreover, if such an asynchronous state ma- 
chine was implemented in fast programmable logic 
array (PAL) devices, the transition of the state ma- 
chine from one state to another might be slower than 
the propagation delay of a single PAL due to the 
amount of circuitry required to build the asynchron- 
ous state machine. One or more PALs might have to 
be stacked in order to implement the state equations 
of the asynchronous state machine. The term 
"stacked" is used herein to indicate an arrangement 
where a first PAL sends one or more signals to a sec- 
ond PAL which then sends one or more signals back 
to the first PAL or to other PALs which in turn even- 
tually send signals to the first PAL. Each time a PAL 
is stacked to implement a state equation, a PAL delay 
is added to the transition time for the corresponding 
state. Thus, implementing the protocol of the connec- 
tion phase as an asynchronous state machine would 
require the use of a large number of logic circuits, and 
if the asynchronous state machine is implemented 
through PAL devices, it may be necessary to stack 
PALS which would slow the asynchronous state ma- 
chine down, thereby, at least partially negating the 
presumed speed advantage of the asynchronous 
state machine over the first synchronous state ma- 
chine 50. 

Referring again to FIG. 3, as mentioned previous- 
ly, the first asynchronous state machine 51 receives 
a line carrying the NO_CONN_HOLD signal 50b from 
the first synchronous state machine 50. The first 
asynchronous state machine 51 also receives a line 
carrying the FB_R_AS signal 24a from the asyn- 
chronous bus interface 20 address circuitry 22 (FIG. 
2). The FB_R_AS signal 24a is a received version of 
the FB_AS signal on the asynchronous I/O bus as op- 
posed to the transmitted version, i.e., FB_T_AS 34b, 
which is asserted by the master controller 34 (FIG. 2) 
when the I/O device 12c is the bus master device. The 
first asynchronous state machine 51 provides a line 
carrying a signal 51a, i.e„ FB_T_AK, which is the 
transmit version of the asynchronous address ac- 
knowledge signal, i.e., FB_AK, on the asynchronous 
I/O bus. The first asynchronous state machine 51 fur- 
ther provides a line carrying a signal 51b, i.e., 
FB_T_AI, which is the transmit version of the asyn- 
chronous address acknowledge inverse signal, i.e., 
FB_AI. Both the FB_T_AK signal 51a and the 
FB_T_AI signal 51 b are sent to t he asynchronous bus 
interface 20 handshake circuitry 22 for transmission 
on the asynchronous I/O bus as the FB_AI signal and 
the FB_AK signal respectively. 

Referring now to FIG. 5, a state diagram illustrat- 
ing the operation of the first asynchronous state ma- 
chine 51 of FIG. 3 is shown. The first asynchronous 
state machine 51 begins in an ldle_51 state with the 
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FB_T_AK signal 51a deasserted and the FB_T_AI 
signal 51b asserted. The state machine enters the 
ldle_51 state when the NO_CONN_HOLD signal 50b 
is deasserted from a previous transaction and transi- 
tions to a Wt_Sync_1 state when the FB_R_AS signal 5 
24a is asserted indicating a new transaction. The 
first asynchronous state machine 51 waits in the 
Wt_Sync_1 state until the first synchronous state ma- 
chine 50 asserts the NO_CONN_HOLD signal 50b. 
Upon detecting the assertion of the NO_CONN_HOLD 10 
signal 50b, the first asynchronous state machine 51 
transitions to a Wait_End state and completes the 
connection phase handshake signals on the asyn- 
chronous bus by asserting the FB_T_AK signal 51a 
while continuing to assert the FB_T_AI signal 51b. As 15 
described above, the first synchronous state machine 

50 asserts the NO_CONN_HOLD signal 50b after 
the address and command information provided on 
the asynchronous I/O bus 13 (FIG. 1) has been cap- 
tured and the appropriate connection phase status 20 
has been placed on the ST<7:0> lines of the asyn- 
chronous I/O bus. Thus, although thefirst asynchron- 
ous state machine 51 receives the assertion of the 
FB_R_AS signal 24a prior to the first synchronous 
state machine 50 receiving the assertion of the relat- 25 
ed signal, SYNCH_AS 36a, the first asynchronous 
state machine 51 is held off, i.e., unable to enter the 
Wait_End state and complete the connection phase 
protocol, through the use of the NO_CONN_HOLD 
signal 50b until the address and command informa- 30 
tion provided on the asynchronous I/O bus has been 
captured and at least partially decoded by the first 
synchronous state machine 50. 

The first asynchronous state machine 51 will re- 
main in the Wait_End state until the asynchronous I/O 35 
bus transaction is ended which is signified by the 
deassertion of the FB_R_AS signal 24a. The state 
machine will then transition to a Wt_Sync_2 state and 
assert the FB_T_AI signal 51b while continuing to as- 
serttheFB_T_AKsignal51a. Following the assertion 40 
of the NO_CONN_HOLD signal 50b by the first syn- 
chronous state machine 50, while the first asynchron- 
ous state machine 51 is in Wt_Sync_2 state, the first 
asynchronous state machine transitions to the 
ldle_51 state to wait for another asynchronous I/O 45 
bus transaction and deasserts the FB_T_AK signal 
51a while continuing to assert the FB_T_AI signal 

51 b. As described above, the first synchronous state 
machine 50 asserts the NO_CONN_HOLD signal 

50b after capturing disconnection phase data sent by so 
the bus master device on the data lines if necessary 
and after placing status on the ST<7:0> lines. 

Here the first asynchronous state machine 51 is 
a simple state machine comprised of four states. 
Therefore, the requirement of having only one state 55 
bit change per state transition does not effect the 
number of state bits necessary to implement the 
asynchronous state machine. For example, the states 



of the first asynchronous state machine 51 may be 
represented by two state bits, i.e., Y0 and Y1. The 
state bits Y0, Y1 may be used internally by the circui- 
try of the state machine or the logic levels of the bits 
may be carried on output lines of the state machine 
(not shown) to be used by other circuitry. By permit- 
ting only one bit to change per state transition by using 
so called "Gray" coding, the state bits Y0, Y1 for the 
ldle_51 state may equal "00", i.e., 0 represents a 
deasserted state bit while 1 represents an assert- 
ed state bit, and the Wt_Sync_1, Wait_End, and 
Wt_Sync_2 states may be represented by the state 
bits Y0, Y1 equaling, "01 "11", and "1 0", respectively. 
No additional state bits are required to implement the 
four states of the first asynchronous state machine 
while still only permitting one state bit to change per 
state transition. 

Referring now to FIG. 6, a truth table is shown 
which corresponds to the first asynchronous state 
machine 51 of FIG.s 3 and 5. A"0" or a "1" in the truth 
table of FIG. 6 represents a deasserted or an assert- 
ed bit, respectively. An "X" in the truth table repre- 
sents a "don't care" bit, i.e., that bit is irrelevant with 
respect to the outputs of the state machine. The first 
and second columns represent the current assertion 
levels of the state bits Y0 and Y1 of the state machine. 
For example, Y0, Y1 equal to "00" represents that the 
first asynchronous state machine is currently in the 
ldle_51 state, "01" represents the Wt_SyncJ state, 
"11" represents the Wait_End state, and "10" repre- 
sents the Wt_Sync_2 state (FIG. 5). The third column 
of the truth table represents the assertion level of the 
FB_R_AS signal 24a, and the fourth column repre- 
sents the assertion level of the NO_CONN_HOLD 
signal 50b. The fifth and sixth columns of the truth ta- 
ble represent the next state assertion levels, i.e., 
Y0' and Y1\ of the state bits Y0 and Y1 of the state 
machine. The seventh column represents the asser- 
tion level of the first asynchronous state machine 51 
output signal FB_T_AK 51a, and the eighth column 
represents the assertion level of the output signal 
FB_T_AI51b. 

The next state bits Y0* and Y1' (columns five and 
six) and the state machine output signals FB_T_AK 
51a and FB_T_AI 51 b (columns seven and eight) are 
determined from the current state bits Y0 and Y1 (col- 
umns one and two) and the state machine input sig- 
nals FB_R_AS 24a and NO_CONN_HOLD 50b (col- 
umns three and four) according to the state diagram 
shown in FIG. 5. For example, the second row of the 
truth table of FIG. 6 shows that the current state is 
the ldle_51 state, i.e., state bits Y0 and Y1 equal 
"00", the FB_R_AS signal 24a is deasserted, and 
the NO_CONN_HOLD signal 50b is irrelevant, i.e., 
"X". The state diagram shown in FIG. 5 indicates that 
given these conditions, the first asynchronous state 
machine 51 will transition to the Wt_Sync_1 state, 
i.e., represented by Y0' and Y1' in the fifth and sixth 
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columns, row 2 equal to "01", and assert the 
FB_T_AK signal 51a and the FB_TAI signal 51b, 
shown in columns seven and eight, row two as "11". 

Referring now to FIG. 7, a Karnaugh map is 
shown which illustrates the conditions under which 5 
the first asynchronous state machine 51 output signal 
FBJT_AK 51 a will be asserted according to the truth 
table of FIG. 6. A"1" in the Karnaugh map represents 
a condition when the FB_T_AK signal 51a will be as- 
serted, whereas, a "0" represents when the FB_T_AK 10 
signal 51a will not be asserted. Through the Kar- 
naugh map, the equation for the FB_T_AK signal 51a 
can be determined. For a corresponding synchron- 
ous state machine, the equation, after term reduction, 
would be: [{(NOT Y0) AND FB_R_AS 24a} OR {Y0 15 
AND Y1} OR {Y0 AND (NOT FB_R_AS 24a) AND 
NOT NO_CONN_HOLD 50b}]. The three terms of 
this equation separated by the "OR" function, are 
shown through the three groupings of T's bounded 
by solid lines in the Karnaugh map of FIG. 7. How- 20 
ever, it is necessary to add the hazard term: OR {Y1 
AND FB_R_AS 24a}, shown through the grouping of 
'Ts bounded by dashed lines in the Karnaugh map 
of FIG. 7, for the first asynchronous state machine 51 . 
As previously mentioned, the addition of hazard 25 
terms to the output equations and state equations of 
asynchronous state machines prevents a glitch on a 
state machine input signal or state bit from causing 
the asynchronous state machine to enter an incorrect 
state. Similar Karnaugh maps for the generation of 30 
equations, including hazard terms, for the state ma- 
chine output signal FB_T_AI 51b and for the first 
asynchronous state machine 51 state bits Y0 and Y1 
can be produced from the truth table of FIG. 6. 

A corresponding synchronous state machine de- 35 
signed to operate in the same way as the first asyn- 
chronous state machine 51 would require less circui- 
try only in that the hazard term would not be required. 
However, synchronous state machines are only per- 
mitted to change state when the state equation is true 40 
and the CLK signal 38a transitions. On the other 
hand, the first asynchronous state machine 51 will re- 
spond immediately, i.e., as soon as the delay through 
the circuitry of the state machine permits, to the as- 
sertion of the FB_R_AS signal 24a by asserting the 45 
FB_T_AK signal 51a and will also respond imme- 
diately to the assertion of the NO_CONN_HOLD sig- 
nal 50b by either deasserting the FB_T_AI signal 51 b 
ordeasserting the FB_T_AK signal 51a. Accordingly, 
the first asynchronous state machine 51 is signtfi- so 
cantly faster than a corresponding synchronous state 
machine, because the asynchronous state machine 
will transition to a next state as soon as the state 
equation becomes true. 

The first asynchronous state machine 51 is used 55 
here to provide the connection phase handshake sig- 
nals in response to only a few input signals. The many 
determinations required during the connection phase 



are accomplished by the first synchronous state ma- 
chine 50 which then allows the first asynchronous 
state machine 51 to quickly respond with the connec- 
tion phase handshake signals once the determina- 
tions are complete. The savings achieved by the 
small increase in circuitry required to implement the 
state machine 51 asynchronously is here not enough 
to justify the loss in speed which would be experi- 
enced in using a synchronous state machine. 

Referring again to FIG. 3, in addition to the GO 
signal 50c from the first synchronous state machine 
50, the second synchronous state machine 52 re- 
ceives a line carrying signal 27c, i.e., READ, from the 
asynchronous interface 20 command circuitry 27 
(FIG. 2). The READ signal 27c is a command decode 
signal which when asserted, indicates that the bus 
master device is requesting a read transaction and 
when deasserted, indicates that the bus master de- 
vice is requesting a write transaction. The second 
synchronous state machine 52 further receives lines 
carrying the SYNCH_AS signal 36a and the 
SYNCH_DS signal 36b and lines from the second 
asynchronous state machine 53 carrying a state bit 
signal 53a, i.e., SO, and a signal 53c, i.e., FLOJTHRU. 
The second synchronous state machine 52 also re- 
ceives the CLK signal 38a, as previously mentioned. 

Additionally, the second synchronous state ma- 
chine 52 receives a line carrying a buffer ready signal 
44b, i.e., BUFFER_READY ( from the control logic 44 
in gate array 40 (FIG. 2). Similar to the BUF- 
FER_AVAILABLE signal 44a sent by the control logic 
44 to the first synchronous state machine 50, the buffer 
ready circuitry which generates the BUFFER_READY 
signal 44b could be located in the slave controller 32 
(FIG. 2) and additional signals sent from the gate ar- 
ray to the slave controller. Again, in this example, the 
buffer ready circuitry (not shown) is located in the 
control logic 44 of the gate array 40 to allow for a cen- 
tralized location of the circuitry and provide the flex- 
ibility that the large amount of circuitry available in 
the gate array provides. The BUFFER_READY signal 
44b is used to indicate that a data buffer in the bank 
of data buffers 42a, 42b in gate array 40 is ready. The 
term "ready" as used herein indicates that a data buf- 
fer contains data retrieved from the main memory to 
be sent to the asynchronous I/O bus in the case of a 
bus master device initiated read. 

The second synchronous state machine 52 pro- 
vides several lines carrying signals, including the 
FORCEJ.T signal 52a which is used to control the 
asynchronous interface 20 address circuitry 22 and 
data circuitry 28 (FIG. 2). The FORCEJ.T signal 52a 
may be one signal or a group of signals designed to 
control transceivers in the address circuitry 22 and 
data circuitry 28 during the first data beat of a trans- 
action (or the second data beat if the transaction is a 
partial transaction). The FORCE_LT signal 52a may 
also be used to transfer subsequent data beats which 
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are loaded into or retrieved from a first location of a 
data buffer in the bank of data buffers 42a, 42b of the 
gate array 40 (FIG. 2) during a transaction. The sec- 
ond synchronous state machine 52 also generates a 
signal 52b, i.e., FETCH, which is sent to the control 
logic 44 in gate array 40 to cause the control logic to 
retrieve a data bufferor more of data through the sys- 
tem bus interface 46 of the gate array 40 from main 
memory 12b on the system bus 12d (FIG. 1). Lastly, 
the second synchronous state machine 52 generates 
a signal 52d used to transfer transaction control to the 
second asynchronous- state machine 53, i.e., 
SET_FLO_THRU. 

With these signals, the first synchronous state 
machine 50 deasserts the NO_CONN_HOLD signal 
50b allowing the first asynchronous state machine 51 
to produce the FB_T_AK signal 51a and the FB_T_AI 
signal 51 b to respond to the connection phase hand- 
shake signals sent by the bus master device as re- 
quired by the asynchronous bus 13. Concomitant 
therewith, the first synchronous state machine 50 
passes control of the transaction to the second syn- 
chronous state machine 52. The second synchronous 
state machine 52 responds to a beginning portion of 
the data transfer phase of a transaction before pass- 
ing transaction control to the second asynchronous 
state machine 53 which produces signals which are 
sent to the asynchronous interface 20 handshake cir- 
cuitry 24 to provide the actual data phase handshake 
signals on the asynchronous I/O bus 13. In one em- 
bodiment of the invention, the second asynchronous 
state machine 53 completes the data transfer phase 
of the transaction by transferring all data beats initi- 
ated by the bus master device between the I/O device 
and the asynchronous bus. Adata beat is one transfer 
of data between two devices on the asynchronous 
bus over the data lines of the asynchronous bus, i.e., 
AD<31:0> and possibly AD<63:32>, D<127:64>, and 
D<255:128>. In another embodiment of the invention 
and the one which will be described herein, the sec- 
ond asynchronous state machine 53 transfers data 
beats between the I/O device and the asynchronous 
bus until a data buffer in the bank of data buffers 42a, 
42b of the gate array 40 (FIG. 2) is filled (write) or 
emptied (read), and then passes control of the trans- 
action back to the second synchronous state machine 
52. The second synchronous state machine 52 then 
returns transaction control to the second asynchron- 
ous state machine 53 following the transfer of subse- 
quent data beat to a first location in a data buffer 
(read) or from a first location in a data buffer (write). 

Referring now to FIG. 8, a state diagram illustrat- 
ing the operation of the second synchronous state 
machine 52 of FIG. 3 is shown. The second synchron- 
ous state machine 52 begins in an ldle_52 state and 
may transition to a Write state or a Read state. If the 
state equation: GO 50c AND (NOT READ 27c), is val- 
id, then the second synchronous state machine 52 



transitions to the Write state. The second synchron- 
ous state machine 52 enters the Write state following 
the assertion of the GO signal 50c by the first syn- 
chronous state machine 50 when the bus master de- 

5 vice is initiating a write transaction, i.e., the READ sig- 
nal 27c is deasserted. If the SYNCH AS signal 36a 
deasserts, i.e., NOT SYNCH__AS 36a, while the sec- 
ond synchronous state machine is in the Write state, 
then the state machine transitions backtothe ldle_52 

10 state. If, however, the state equation: SYNCH_AS 
36a AND BUFFER_AVAILABLE 44a AND 
(SYNCH_DS 36b AND (NOT SO 53a) OR (NOT 
SYNCH_DS 36b) AND SO 53a), is or becomes valid 
while the state machine is in the Write state, then the 

15 state machine transitions to a 1st_Db state and as- 
serts the FORCE_LT signal 52a. 

The assertion of the SYNCH_DS signal 36b 
while the second asynchronous state machine 53 
state bit signal SO 53a is deasserted (SYNCH_DS 

20 36b AND (NOT SO 53a)) indicates the beginning of an 
odd data beat. The deassertion of the SYNCH_DS 
signal 36b while the second asynchronous state ma- 
chine 53 state bit signal SO 53a is asserted ((NOT 
SYNCHJDS 36b) AND SO 53a) indicates the begin- 

25 ning of an even data beat Both of these conditions 
will be discussed in more detail with regard to the sec- 
ond asynchronous state machine 53. If either of the 
above conditions is true and the SYNCH_AS signal 
36a is asserted, the second synchronous state ma- 

30 chine 52 responds by asserting the FORCE_LT sig- 
nal 52a which during a write transaction causes the 
transceivers in the asynchronous interface 20 data 
circuitry 28 (FIG. 2) to receive data during the first 
data beat on the asynchronous I/O bus. 

35 For most transactions, the second synchronous 
state machine 52 will respond to the first odd data 
beat, i.e., SYNCH J)S 36b and (NOT SO 53a). How- 
ever, in the case of a partial transaction, the first syn- 
chronous state machine 50 responds to the first odd 

40 data beat which carries the mask data, and, there- 
fore, the second synchronous state machine 52 re- 
sponds to a first even data beat, i.e., (NOT 
SYNCH_DS 36b) AND SO 53a. The second synchron- 
ous state machine 52 need not check that the BUF- 

45 FER_AVAILABLE signal 44b is asserted in order to 
respond to the first data beat (odd or even) of a write 
transaction, because it is implicit in the assertion of 
the GO signal 50c from the first synchronous state 
machine 50 that a data buffer is available. The GO 

so signal 50c is not asserted unless the BUF- 
FER_AVAILABLE signal 44a is asserted which indi- 
cates that a data buffer in the bank of data buffers 
42a, 42b in gate array 40 (FIG. 2) is available to store 
data received from the asynchronous I/O bus 13 or 

55 the synchronous system bus 12d (FIG. 1). However, 
in responding to each data beat which is to be stored 
in a first location in a subsequent data buffer, the sec- 
ond synchronous state machine 52 does need to 
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check that a data buffer is ready to store additional 
data, i.e., the BUFFER_AVAILABLE signal 44a is as- 
serted. 

While in the ldle_52 state, if the state equation: 
GO 50c AND READ 27c, is or becomes valid, then the 
second synchronous state machine 52 transitions to 
a Wt_Read state. The second synchronous state ma- 
chine 52 enters the Wt_Read state following the as- 
sertion of the GO signal 50c by the first synchronous 
state machine 50 when the bus master device is ini- 
tiating a read transaction, i.e., the READ signal 27c is 
asserted. The Wt_Read state is a wait state during 
which the asynchronous interface 20 data circuitry 28 
(FIG. 2) is prepared to drive data onto the asynchron- 
ous bus (the number of wait states may vary depend- 
ing on the characteristics of the asynchronous inter- 
face). 

The second synchronous state machine 52 tran- 
sitions from the Wt_Read state to a Read state auto- 
matically on the next transition of the CLK signal 38a. 
If the SYNCH_AS signal 36a deasserts, i.e., NOT 
SYNCH_AS 36a, while the second synchronous state 
machine is in the Read state, then the state machine 
transitions back to the ldle_52 state. If, however, the 
state equation: SYNCH_AS 36a AND BUFFER_REA- 
DY 44b AND (SYNCHJDS 36b AND (NOT SO 53a) 
OR (NOT SYNCH_DS 36b) AND SO 53a), becomes 
valid while the state machine is in the Read state, 
then the state machine transitions to the 1st_Db state 
and asserts the FORCEJT signal 52a. This state 
equation is similar to the state equation required to be 
valid for the state machine to transition from the Write 
state to the 1st_Db state, except that this state equa- 
tion requires the BUFFER_READY signal 44b to be 
asserted. 

During a read transaction, the second synchron- 
ous state machine 52 waits until the system bus inter- 
face logic 46 in gate array 40 (FIG. 2) has retrieved 
necessary data from main memory 12b and filled at 
least one data buffer in the bank of data buffers 42a, 
42b of the gate array 40 with necessary data before 
asserting the FORCE_LT signal 52a. During a read 
transaction, the FORCEJ.T signal 52a is used to 
cause the transceivers in the asynchronous interface 
20 address circuitry 22 and data circuitry 28 (FIG. 2) 
to place data to be sent in the first data beat (odd or 
even) onto the asynchronous I/O bus. 

Following the 1st_Db state, the state diagram of 
FIG. 8 includes wait states Wait_6 and Wait_7. These 
wait states are here added to allow the I/O device to 
drive data from the bank of data buffers 42a, 42b in 
gate array 40 (FIG. 2) onto the asynchronous I/O bus 
in the case of a read transaction or to allow the I/O de- 
vice to receive data from the asynchronous I/O bus 
and load the data into a data buffer in the bank of data 
buffers 42a, 42b in gate array 40 in the case of a write 
transaction (the number of wait states may vary de- 
pending on the characteristics of the asynchronous 



I/O bus, the asynchronous interface 20, and the gate 
array 40). When the data has been driven onto the 
asynchronous I/O bus and is valid in the case of a 
read or when the data has been loaded into a data 

5 buffer in the case of a write, the second synchronous 
state machine 52 transitions to the Async_Db state 
and asserts the SET_FLO_THRU signal 52d. The 
second asynchronous state machine 53 immediately 
asserts the FLOJTHRU signal 53c upon detecting 

10 the assertion of the SET_FLO_THRU signal 52d. The 
second synchronous state machine 52 will receive 
the assertion of the FLOJTHRU signal 53c prior to 
the next transition of the CLK signal 38a. The asser- 
tion of the SET_FLO_THRU signal 52d allows the 

15 second asynchronous state machine 53 to complete 
the transfer of the data beat (odd or even) and to re- 
spond to subsequent data beats in the transaction. 
This will be described in more detail with regard to the 
second asynchronous state machine 53. 

20 While in the Async_Db state, if the transaction 
ends, signified by the deassertion of the SYNCH_AS 
signal 36a, the second synchronous state machine 52 
transitions back to the ldle_52 state. Otherwise, the 
second synchronous state machine 52 remains in the 

25 Async_Db state until the second asynchronous state 
machine 53 passes transaction control back to the 
second synchronous state machine 52 by deassert- 
ing the FLOJTHRU signal 53c, i.e., NOT FLOJTHRU 
53c. The second asynchronous state machine 53 may 

30 pass transaction control back to the second syn- 
chronous state machine 52 when a data buffer in the 
bank of data buffers 42a, 42b in gate array 40 (FIG. 
2) has been filled or emptied depending on whether 
the transaction was a read or write transaction, re- 

35 spectively. With the deassertion of the FLOJTHRU 
signal 53c, the second synchronous state machine 52 
may transition to either the Write state or the 
Next_Buf state. 

In the case of a write, i.e., NOT READ 27c, the 

40 second synchronous state machine 52 transitions 
from the Async_Db state to the Write state and waits 
for the assertion of the BUFFER_AVAILABLE signal 
44a and for the beginning of the next data beat The 
second synchronous state machine 52 needs to 

45 check that a data buffer in the bank of data buffers 
42a, 42b is empty (available) and therefore, able to 
accept data from the asynchronous I/O bus before 
continuing to accept the next data beat in a write 
transaction. Thus, the second synchronous state ma- 

50 chine 52 waits for the assertion of the BUF- 
FER_AVAILABLE signal 44a. 

In the case of a read, i.e., the READ signal 27c 
is asserted, the second synchronous state machine 
52 transitions from the Async_Db state to wait state 

55 Next_Buf and asserts the FETCH signal 52b. In one 
embodiment of the invention, the FETCH signal 52b 
causes the control logic 44 in gate array 40 (FIG. 2) 
to cause a previously filled data buffer in the bank of 
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data buffers 42a, 42b in gate array 40 to supply data 
to the asynchronous interface 20 and to cause the 
system bus interface logic 46 to retrieve subsequent 
necessary data from main memory 1 2b (FIG. 1) to fill 
the data buffer just emptied. In another embodiment 
of the invention where there may only be one data 
buffer or data buffers are not filled with data before it 
is needed, the FETCH signal 52b causes the control 
logic 44 in gate array 40 to cause the system bus in- 
terface logic 46 to retrieve subsequent necessary 
data from main memory 12b to fill a data buffer. This 
second embodiment may take more time due to the 
necessity of having the system bus interface logic 46 
retrieve the necessary data. On the next transition of 
the CLK signal the second synchronous state ma- 
chine transitions to the Read state to wait for the as- 
sertion of the BUFFER_READY signal 44b and the 
beginning of the next data beat. 

The second synchronous state machine 52 may 
flow through the Write or Read state, 1 st_Db, Wait_6, 
Wait_7, and Async_Db states and possibly the 
Next_buf state many times depending on the number 
of data buffers worth of data which is being transfer- 
red in the current transaction. As mentioned above, a 
second asynchronous state machine 53 could be de- 
signed such that it completes the transfer of all the 
data beats initiated by the bus master device and 
such that the second synchronous state machine 52 
will only flow through the state diagram of FIG. 8 
once, not including the Next_Buf state, i.e., in the 
AsyncJDb state the state machine would wait for the 
end of the transaction signified by the deassertion of 
the SYNCH_AS signal 36a and then transition to the 
ldle_52 state. However, in such an embodiment, the 
complications arising around different data buffers in 
the bank of data buffers 42a, 42b in gate array 40 
(FIG. 2) supplying the data or the need to retrieve 
data from the main memory would complicate the 
second asynchronous state machine 53, and there- 
fore, the second asynchronous state machine 53 of 
the preferred embodiment passes transaction control 
back to the second synchronous state machine 52 to 
respond to the transfer of each data beat to a first lo- 
cation in a subsequent data buffer. 

Implementing the protocol of the beginning of the 
data phase as the second synchronous state ma- 
chine 52 provides a slower state machine than if the 
protocol were implemented as a corresponding asyn- 
chronous state machine due to the necessity of syn- 
chronizing the FB_R_AS signal 24a, i.e., SYNCH_AS 
36a, and the FB_R_DS signal 24b, i.e., SYNCH_DS 
36b, (FIG. 2) as previously discussed. The second 
synchronous state machine 52 may also be slower 
than a corresponding asynchronous state machine, 
because the synchronous state machine will not 
change state until the appropriate state equation is 
true and the CLK signal transitions, whereas a corre- 
sponding asynchronous state machine will change 



state as soon as the appropriate state equation be- 
comes true. 

However, implementing the beginning of the data 
phase as the second synchronous state machine 52 

5 allows the state machine to take different paths at 
stages in the first data transfer where a read or a write 
transaction have different requirements. As men- 
tioned previously, asynchronous state machines al- 
low only one state bit to change per state transition, 

10 and, therefore, synchronous state machines are gen- 
erally better suited than asynchronous state ma- 
chines for implementing different paths from one 
state into many other states. Asynchronous state ma- 
chine also allows wait states to be easily added to the 

15 many paths that may be required of the state machine 
to allow sufficient time for specific circuitry to be set 
up or for signals to propagate through specific circui- 
try. If the protocol of the beginning of the data phase 
were implemented as a corresponding asynchronous 

20 state machine, the corresponding asynchronous 
state machine would, in general, be very large requir- 
ing significantly more circuitry than the second syn- 
chronous state machine 52 due to the requirement of 
having only one state bit change per state transition 

25 and also due to the necessity of including hazard 
terms in the state equations, as previously discussed. 
Also, there exists the possibility that PAL stacking, as 
previously discussed, might partially negate the 
speed increase associated with an asynchronous 

30 state machine. 

Referring again to FIG. 3, as previously men- 
tioned, the second asynchronous state machine 53 
receives a line carrying the LT_MASK signal 50e from 
the first synchronous state machine 50 and a line car- 

35 rying the SET_FLO_THRU signal 52d from the sec- 
ond synchronous state machine 52. The second 
asynchronous state machine also receives lines car- 
rying the FB_R_AS signal 24a and the FB_R_DS sig- 
nal 24b from the asynchronous interface 20 hand- 

40 shake circuitry 24 (FIG. 2) and a line carrying the 
SLAVE signal 22a from the asynchronous interface 
20 address circuitry 22. In addition, the second asyn- 
chronous state machine 53 receives lines carrying 
delayed versions of the FB_R_DS signal 24b, i.e., the 

45 NO_HOLD_ODD signal 48a and the NO_HOLD_EVEN 
signal 48b, from the delay logic 48 shown in FIG. 3. 

The second asynchronous state machine 53 also 
receives a signal 44c, i.e., LAST_DB, indicating that 
the current data buffer having data loaded into it or re- 

50 moved from it in the bank of data buffers 42a, 42b of 
the gate array 40 (FIG. 2) can only store or provide, 
respectively, data sufficient for one more data beat. 
The control logic 44 in gate array 40 provides the 
LAST_DB signal 44c and has circuitry (not shown) for 

55 determining from the address and command informa- 
tion captured from the asynchronous I/O bus that only 
one data beat can be loaded into or removed from the 
current data buffer. Similar to the buffer available cir- 
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cuitry and buffer ready circuitry, the last data beat cir- 
cuitry could be located in the slave controller 32 (FIG. 
2). 

As shown in FIG. 3, the delay logic 48 receives 
the FB_R_DS signal 24b and the FB_R_AS signal 5 
24a from the asynchronous interface 20 handshake 
circuitry 24 (FIG.2). The delay logic 48 also receives 
the READ signal 27c and the DATA_LINES<1:0> sig- 
nals 27d from the asynchronous interface 20 com- 
mand circuitry 27, and the state bit SO signal 53a from w 
the second asynchronous state machine 53. The 
DATA_LINES<1:0> signals 27d indicate which data 
lines will be used to transfer data during the current 
transaction. 

In addition to t he NO_HOLD_ODD signal 48a and 15 
the NO_HOLD_EVEN signal 48b, the delay logic 48 
provides a BUFFER_DS signal 48c. This signal is 
sent to the control logic 44 of the gate array 40 (FIG. 
2) and used by the control logic 44 to increment to the 
next location in the current data buffer. A counter in 20 
the control logic 44 will provide the LAST_DB signal 
44c to the second asynchronous state machine 53. 

The NO_HOLD_ODD signal 48a is used in rela- 
tion to the assertion of the FB_R_DS signal 24b to 
signify that the odd data beat (the state bit SO signal 25 
53a is asserted) data has been captured from the 
asynchronous I/O bus in the case of a write (the 
READ signal 27c is deasserted) or that the odd data 
beat data has been placed on the asynchronous I/O 
bus in the case of a read (the READ signal 27c is as- 30 
serted). The NO_HOLD_EVEN signal 48b is used in 
relation to the deassertion of the FB_R_DS signal 
24b to signify that the even data beat (the state bit SO 
signal 53a is deasserted) data has been captured 
from the asynchronous I/O bus in the case of a write 35 
or that the even data beat data has been placed on the 
asynchronous I/O bus in the case of a read. The delay 
logic 48 contains delay circuitry and control circui- 
try (not shown) to control the length of time the 
NO_HOLD_ODD signal 48a and the NO_HOLD_EVEN 40 
signal 48b are delayed in relation to the FB_R_DS 
signal 24b. 

The length of time that the NO_HOLD_ODD sig- 
nal 48a and the NO_HOLD_EVEN signal 48b are de- 
layed in relation to the FB_R_DS signal 24b may vary 45 
depending upon the transaction. One factor in the 
amount of time needed is the number of data lines 
which will be used to transfer data, as indicated by the 
DATAJJNES<1:0> signals 27d..For example, if the 
data buffers in the bank of data buffers 42a, 42b in the so 
gate array 40 (FIG. 2) are thirty-two bits wide, a thir- 
ty-two bit data width transaction on the asyn- 
chronous I/O bus would require less delay of the 
NOJHOLD_ODD signal 48a and the NO_HOLD_EVEN 
signal 48b in relation to the FB_R_DS signal 24b than 55 
a sixty-four bit data width transaction. This is because 
a sixty-four bit data width transaction requires that 
two locations be retrieved from a data buffer in the 



case of a read and that two locations be loaded into 
a data buffer in the case of a write, while a thirty-two 
bit transaction requires only one location to be re- 
trieved or loaded. Similarly, a one-hundred and twen- 
ty-eight bit data width transaction on the asyn- 
chronous I/O bus would require a longer delay of the 
NOJHOLD_ODD signal 48a and the NO_HOLD_EVEN 
signal 48b in relation to the FB_R_DS signal 24b than 
a sixty-four bit data width transaction. 

As shown in FIG. 3, the second asynchronous 
state machine 53 provides lines carrying the data 
phase handshake signals 53d and 53e, i.e., 
FB_T_DK and FB_T_DI, respectively. As mentioned 
previously, the second asynchronous state machine 
53 further provides lines to the second synchronous 
state machine 52 carrying a second asynchronous 
state machine 53 state bit, i.e., the SO signal 53a, and 
the FLO_THRU signal 53c. With these signals, the 
second asynchronous state machine 53 can respond 
to data beats initiated by the bus master device and 
return transaction control to the second synchronous 
state machine 52 either at the end of the transaction, 
i.e., the FB_R_AS signal 24a deasserts, or following 
the filling or emptying of a data buffer, i.e., the 
LAST_DB signal 44c asserts. 

Referring now to FIG. 9, a state diagram illustrat- 
ing the operation of the second asynchronous state 
machine 53 of FIG. 3 is shown. The second asyn- 
chronous state machine 53 begins in an End_Even 
state, represented by state bits SO (signal SO 53a) and 
S1 equal to "00", with the FB_T_DK signal 53d and 
the FB_T_DI signal 53e deasserted. The state ma- 
chine asserts the FB_T_DI signal 53e at the begin- 
ning of a transaction, while remaining in the End- 
_Even state, when the FB_R_AS signal 24a and the 
SLAVE signal 22a become asserted, i.e., FB_R_AS 
24a AND SLAVE 22a, in preparation for future use. 
The second synchronous state machine 53 transi- 
tions to a Beg_Odd state, represented by state bits SO 
and S1 equal to "Or, when the state equation: 
FB_R_AS 24a AND SLAVE 22a AND FB_R_DS 24b, 
becomes valid. The assertion of FB_R_DS 24b indi- 
cates that the bus master device is initiating the first 
odd data beat. Upon the transition to the Beg_Odd 
state, the second asynchronous state machine 53 as- 
serts the FB_T_DK signal 53d and continues to as- 
sert the FBJTJDI signal 53e. 

While in the BegJDdd state, if the state equation: 
FB_R_AS 24a AND SLAVE 22a AND FB_R_DS 24b 
AND NO_HOLD_ODD 48a AND (FLO JTHRU 53c OR 
LT_MASK 50e), becomes valid, then the state ma- 
chine will transition to the End_Odd state, represent- 
ed by state bits SO and S1 equal to "11", and deassert 
the FB_T_DI signal 53e to complete the first odd data 
beat while continuing to assert the FB_T_DK signal 
53d. The assertion of the NO_HOLD_ODD signal 48a 
indicates that the data on the asynchronous I/O bus 
has been captured in the case of a write or that the 
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data has been placed on the asynchronous I/O bus in 
the case of a read. The assertion of the LT_MASK sig- 
nal 50e indicates that the transaction is a partial 
transaction and the first synchronous state machine 

50 has caused the mask data to be latched. The as- s 
sertion of the FLO_THRU signal 53c indicates that 

the second synchronous state machine 52 has as- 
serted the SET_FLO_THRU signal 52d which indi- 
cates that the transaction is not a partial and that the 
data for the first odd data beat has been stored in a 10 
data buffer of the bank of data buffers 42a, 42b of the 
gate array 40 (FIG. 2) in the case of a write or that the 
data has been placed on the asynchronous I/O bus in the 
case of a read. The assertion of the SET_FLOJTHRU 
signal 52d also indicates that the second synchron- 15 
ous state machine 52 has passed transaction control 
to the second asynchronous state machine 53 such 
that subsequent data beats initiated by the bus mas- 
ter device should be responded to by the second 
asynchronous state machine 53 until the LAST_DB 20 
signal 44c asserts. 

As previously mentioned, the assertion of the 
SET_FLO_THRU signal causes the second asyn- 
chronous state machine 53 to immediately assert the 
FLOJTHRU signal 53c (the equation is not shown in 25 
FIG. 9) to the second synchronous state machine 52. 
The second asynchronous state machine 53 will keep 
the FLO_THRU signal 53c asserted until the control 
logic 44 in gate array 40 (FIG. 2) asserts the 
LAST_DB signal 44c and the second asynchronous 30 
state machine 53 has transferred that last data beat 
to or from a data buffer in the bank of data buffers 
42a, 42b in gate array 40, or until the FB_R_AS signal 
24a has deasserted. 

While in the End_Odd state, if the state equation: 35 
FB_R_AS 24a AND SLAVE 22a AND (NOT FB_R_DS 
24b), becomes valid, the state machine transitions to 
the Beg_Even state, represented by state bits SO and 

51 equal to "1 0", and asserts the FB_T_DI signal 53e 

in preparation for later use while continuing to assert 40 
the FB_T_DK signal 53d. The deassertion of the 
FB_R_DS signal 24b while the FB_R_AS signal 24a 
is asserted indicates that the bus master device is ini- 
tiating an even data beat. 

While in the Beg_Even state, if the state equa- 45 
tion: FB_R_AS 24a AND SUWE 22a AND (NOT 
FB_R_DS 24b) AND NO_HOLD_EVEN 48b AND 
FLOJTHRU 53c ( becomes valid, the state machine 
transitions to the End_Even state and deasserts the 
FB_T_DK signal 53d to complete the even data beat 50 
while continuing to assert the FB_T_DI signal 53e. 
The assertion of the NO_HOLD_EVEN signal 48b in- 
dicates that the data for the even data beat has been 
captured from the asynchronous I/O bus and stored 
in a data buffer of the bank of data buffers 42a, 42b 55 
of the gate array 40 (FIG. 2) in the case of a write or 
that the data has been retrieved from a data buffer 
and placed on the asynchronous I/O bus in the case 



of a read. The assertion of the FLO_THRU signal 53c 
indicates that the SET_FLO_THRU signal 52d has 
asserted which indicates that the second synchron- 
ous state machine 52 has captured data for the first 
even data beat in the case of a write or provided data 
for the first even data beat in the case of a read and 
has passed transaction control to the second asyn- 
chronous state machine 53 following the first syn- 
chronous state machine 50 latching the mask data, or 
the assertion of the SET_FLO_THRU signal 52d in- 
dicates that the second synchronous state machine 
52 is continuing to pass transaction control to the sec- 
ond asynchronous state machine 53. 

The states of the second asynchronous state ma- 
chine 53 will be repeated for as many data beats as 
are initiated by the bus master device oruntil the con- 
trol logic 44 in the gate array 40 (FIG. 2) asserts the 
LAST_DB signal 44c. 

While in the End_Odd state, if the FB_R_AS sig- 
nal 24a deasserts signifying the end of the transac- 
tion, both the FB_T_DK signal 53d and the FB_T_DI 
signal 53e will deassert (not shown in FIG. 9) and the 
second asynchronous state machine 53 will transition to 
the BegLEven state. Following the deassertion of the 
NO_HOLD_EVEN signal 48b, the second asynchron- 
ous state machine 53 will transition to the End_Even - 
state and wait for the next transaction. The state ma- 
chine follows this sequence in order to insure that 
only one state bit changes per state transition. 

Here the second asynchronous state machine 
53, similar to the first asynchronous state machine 
51 , is a simple state machine comprised of four states. 
Therefore, the requirement of having only one state 
bit change per state transition does not effect the 
number of state bits necessary to implement the 
asynchronous state machine. A truth table similar to 
the one of FIG. 6 and a Karnaugh map similar to the 
one of FIG. 7 would be provided for each state bit sig- 
nal and output signal of the second asynchronous 
state machine 53. From the Karnaugh maps, the 
equations for the state bits and output signals could 
be determined, including hazard terms, as outlined 
above. Due to the fact that there are few determina- 
tions to be made in transferring data beyond the 
transfer of a data beat which is to be stored in or re- 
moved from a first location in a data buffer, the sec- 
ond asynchronous state machine does not need to 
make many determinations. Therefore, there is only 
a small increase in circuitry required to implement the 
second asynchronous state machine 53 asynchro- 
nously as opposed to the circuitry which would be re- 
quired to implement a corresponding synchronous 
state machine. 

The data transfer phase of a transaction generally 
comprises most of the transaction. Therefore, a trans- 
action may be completed significantly faster if the 
data can be transferred at a faster rate. Once the sec- 
ond asynchronous state machine 53 has transaction 



18 



35 



EP 0 592 213 A1 



36 



control, the data transfer will take place significantly 
faster than a corresponding synchronous state ma- 
chine would allow for the reasons outlined above. 

The slave controller 32 (FIG. 2) described above 
allows a fast data transfer by implementing the data s 
phase protocol through the second asynchronous 
state machine 53. However, the circuitry of the slave 
controller 32 is at a minimum due to the implementa- 
tion of the connection phase protocol and beginning 
of the data phase protocol through the first and sec- w 
ond synchronous state machines 50 and 52, respec- 
tively. 

The master and slave controllers 34, 32, respec- 
tively, are totally independent, and, therefore, they 
may both be implemented via a combination of syn- 15 
chronous and asynchronous state machines as de- 
scribed above. Alternatively, either one may be imple- 
mented through strictly synchronous circuitry while 
the other is implemented using a combination of syn- 
chronous and asynchronous state machines, as de- 20 
scribed above. If the master controller 34 is imple- 
mented via a combination of synchronous and asyn- 
chronous state machines as outlined above, it would 
be similar to the slave controller 32 except that first 
and second asynchronous state machines would re- 25 
ceive the slave handshake signals from the asyn- 
chronous I/O bus and provide the master handshake 
signals to the asynchronous I/O bus, and the master 
controller 34 would provide the address and com- 
mand information and receive the status information. 30 
The signals necessary to implement the master con- 
troller 34 in accordance with the invention are not 
shown in FIG. 2 for simplicity. 

Although the preferred embodiment of the inven- 
tion has been described in reference to an I/O device 35 
providing data transfer between a synchronous sys- 
tem bus and an asynchronous I/O bus, it will become 
apparent to one of skill in the art that the data transfer 
device may interface other synchronous systems to 
asynchronous busses and devices. For example, the 40 
data transfer device described above may be used to 
provide data transfer between a synchronous mem- 
ory device or CPU and an asynchronous bus on which 
they are resident Two data transfer devices may be 
used to interface to two asynchronous busses and to 45 
transfer data between the two asynchronous buses, 
i.e., the system bus is asynchronous rather than syn- 
chronous as described above. The complexities of 
the asynchronous busses may make the speed re- 
duction of the data transfer device worth while due to so 
the circuitry savings experienced by using the data 
transfer devices. 

Having described preferred embodiments of the 
invention, it will now become apparent to one of skill 
in the art that other embodiments incorporating their 55 
concepts may be used. Accordingly, it is submitted 
that the invention should not be limited to the dis- 
closed embodiments, but rather should be extended 



to cover all equivalents thereof. 



Claims 

1. A data transfer device for controlling data transfer 
between an asynchronous bus and said data 
transfer device, comprising; 

a synchronous logic network to pro- 
vide a transaction connection between said asyn- 
chronous bus and said data transfer device dur- 
ing an initial phase of said transaction; and 

an asynchronous logic network to 
provide data transfer between said asynchron- 
ous bus and said data transfer device during a 
subsequent phase of said transaction. 

2. The data transfer device according to claim 1, 
wherein said asynchronous logic network com- 
prises; 

means for providing asynchronous bus 
control signals to said asynchronous bus during 
said transaction. 

3. The data transfer device according to claim 2, 
wherein said synchronous logic network com- 
prises; 

means for controlling said transaction dur- 
ing said initial phase of said transaction by provid- 
ing at least one signal to said asynchronous logic 
network to provide in response thereto at least 
one control signal on said asynchronous bus, 
wherein said synchronous logic network further 
comprises; 

means for passing transaction control to 
said asynchronous logic network after said initial 
phase of said transaction and after a beginning 
portion of said subsequent phase of said transac- 
tion. 

4. The data transfer device according to claim 1 , fur- 
ther comprising; 

means, coupled to said controlling means, 
for interfacing said data transfer device to said 
asynchronous bus, wherein said device further 
comprises; 

a data buffer coupled to said asynchron- 
ous bus interfacing means and to said controlling 
means, to store data to be sent to said asynchron- 
ous bus and to store data received from said 
asynchronous bus. 

5. The data transfer device according to claim 4, 
wherein said synchronous logic network further 
comprises; 

means for stalling said asynchronous logic 
network until said data transfer device is ready to 
continue said transaction, wherein said synchron- 
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ous logic network further comprises; 

means, responsive during said initial 
phase of said transaction and to data buffer sta- 
tus signals, command decode signals, and an ad- 
dress decode signal, for determining if said data 5 
transfer device is ready to continue said transac- 
tion, wherein said synchronous logic network fur- 
ther comprises; 

means, responsive during said subse- 
quent data transfer phase of said transaction and 10 
to said data buffer status signals, for determining 
if said data transfer device is ready to continue 
said transaction. 

6. The data transfer device according to claim 4, 15 
wherein said synchronous logic network further 
comprises; 

means for determining that said data buf- 
fer stores data to be transferred during said trans- 
action and for passing transaction control to said 20 
asynchronous logic network, during transfer of 
data to said asynchronous bus; and 

means for determining that said data buf- 
fer is available to store data received during said 
transaction and for passing transaction control to 25 
said asynchronous logic network, during receiv- 
ing data from said asynchronous bus, wherein 
said asynchronous logic network further com- 
prises; 

means for transferring the data stored in 30 
said data buffer for said transaction and for re- 
turning transaction control to said synchronous 
logic network, during transfer of data to said 
asynchronous bus; and 

means for storing data received from said 35 
asynchronous bus in said data buffer for said 
transaction and for returning transaction control 
to said synchronous logic network, during receiv- 
ing data from said asynchronous bus. 

40 

7. The data transfer device according to claim 6, 
wherein said synchronous logic network further 
comprises; 

means for determining that said data buf- 
fer contains additional data to be transferred for 45 
said transaction and for passing transaction con- 
trol back to said asynchronous logic network, 
during transfer of data to said asynchronous bus; 
and 

means for determining that said data buf- 50 
fer is available to store additional data received 
from said asynchronous bus for said transaction 
and for passing transaction control back to said 
asynchronous logic network, during receiving 
data from said asynchronous bus, wherein said 55 
data buffer is a first data buffer and said data 
transfer device further comprises; 

at least a second data buffer; and 



wherein said synchronous logic network 
further comprises; 

means for determining that one of said 
data buffers contains data to be transferred to 
said asynchronous bus for said transaction and 
for passing transaction control to said asynchron- 
ous logic network; and 

means for determining that one of said 
data buffers is available to store data received 
from said asynchronous bus for said transaction 
and for passing transaction control to said asyn- 
chronous logic network. 

8. The data transfer device according to claim 4, 
wherein said device further comprises; 

means responsive to at least a portion of 
an address and a command provided by said 
asynchronous bus for determining a storage lo- 
cation in said data buffer, wherein said device fur- 
ther comprises; 

means responsive to at least a portion of 
an address and a command provided by said 
asynchronous bus for determining an ending lo- 
cation in said data buffer. 

9. The data transfer device according to claim 1, 
wherein said synchronous logic network com- 
prises; 

a first synchronous state machine, com- 
prising; 

means for providing a latch signal to 
capture address and command information pres- 
ent on said asynchronous bus; and 

means for providing a hold signal to 
stall said asynchronous logic network and for de- 
termining that said data transfer device is ready 
to commence said subsequent data transfer 
phase of said transaction, wherein said first syn- 
chronous state machine is responsive to data 
buffer status signals, command decode signals, 
and an address decode signal to determine if said 
data transfer device is ready to commence said 
subsequent data transfer phase of said transac- 
tion, wherein said asynchronous logic network 
comprises; 

a first asynchronous state machine, 

comprising; 

means responsive to said 
hold signal and to an address strobe signal from 
said asynchronous bus for providing at least one 
connection control signal to said asynchronous 
bus to indicate that said subsequent data transfer 
phase may commence. 

10. The data transfer device according to claim 9, 
wherein said first synchronous state machine fur- 
ther comprises; 

means for providing a data phase signal, 
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wherein said synchronous logic network further 
comprises; 

a second synchronous state machine, 
comprising; 

means responsive to said data 
phase signal and to said address strobe signal 
and to a data strobe signal from said asynchron- 
ous bus to control a beginning of said subsequent 
phase of said transaction; and 

means for providing a data hold sig- 
nal to stall said asynchronous logic network and 
for determining that said data transfer device is 
ready to transfer data for said transaction, where- 
in said second synchronous state machine com- 
prises; 

means, responsive to data buffer 
status signals, command decode signals, and 
synchronized control signals from said asyn- 
chronous bus, for determining if said data transfer 
device is ready to transfer data for said transac- 
tion. 

11. The data transfer device according to claim 10, 
wherein said asynchronous logic network further 
comprises; 

a second asynchronous state machine, 
comprising; 

means responsive to said data hold 
signal and to said data strobe signal, for providing 
data transfer signals to said asynchronous bus to 
transfer data between said data transfer device 
and said asynchronous bus. 

12. The data transfer device according to claim 1, 
wherein said controlling means, comprises; 

means for initiating transactions on said 
asynchronous bus. 

13. The data transfer device according to claim 1, 
wherein said controlling means, comprises; 

means for responding to transactions re- 
ceived from said asynchronous bus. 

14. The data transfer device according to claim 1, 
wherein said controlling means is a first control- 
ling means for responding to transactions re- 
ceived from said asynchronous bus, and wherein 
said data transfer device further comprises; 

a second controlling means for initiating 
transactions to be sent to said asynchronous bus. 

15. The data transfer device according to claim 1, 
wherein said device further comprises; 

means for interfacing to a synchronous 
system bus coupled to said data transfer device 
to provide for data transfer between said syn- 
chronous system bus and said asynchronous 
bus. 



16. The data transfer device according to claim 15, 
wherein said system bus is synchronous to a first 
clock signal and said synchronous logic network 
is synchronous to a second clock signal. 

5 

17. A data transfer device, comprising; 

means for interfacing to an asynchronous 
bus; and 

means for controlling data transfer be- 
10 tween said asynchronous bus interfacing means 
and said asynchronous bus, comprising; 

means for synchronously control- 
ling an initial connection phase of a transaction; 
and 

15 means for asynchronously control- 

ling a subsequent data transfer phase of said 
transaction. 

18. A data transfer computer network comprising; 
20 an asynchronous bus; 

a synchronous bus; and 

a first data transfer device coupled be- 
tween said synchronous bus and said asynchron- 
ous bus, said first data transfer device compris- 
25 ing; 

means for controlling data transfer 
between said asynchronous bus and said syn- 
chronous bus, comprising; 

a synchronous logic network 
30 to provide a transaction connection with said 
asynchronous bus during an initial phase of said 
transaction; and 

an asynchronous logic net- 
work to provide data transfer between said asyn- 
35 chronous bus and said first data transfer device 
during a subsequent phase of said transaction. 
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